Is it a common practice to give a user an unmodifiable password? I created an online account on a website, they do not ask me for a password but just an email address, then, after acknowledging "terms of service" I was already logged-in.

Then I received an email with a password (ten characters like automatically generated password) and this advice:

  Please note that passwords are case sensitive. [website name] handles
  sensitive information on behalf of some its members and other
  organisations. To help protect your data, we automatically assign
  secure passwords. To maintain this security, you cannot change
  your password and we have no means of retrieving lost passwords.

This was something I have never seen before and leave me with a lot of doubts about the trustworthiness of the website. I was expecting at least the capability to change the password.

update with more details:
I did not realize immediately I was already logged-in and so I mistakenly logged out, but I was obviously without a password, so I clicked on their "forgot password" and then I had a look at my incoming emails: an older welcome email with the first password and a second newer email due to "forgot password". The password of the older email is working, the password of the newer email does not work. After all, they wrote

  we have no means of retrieving lost passwords.

And they also add:

  Please make sure you do not share your password with anyone. We
  recommend that provided you use a recent browser, you use your web
  browser's "remember password" function to provide ease of access while
  retaining password security.

You are right to be suspicious about this service.

The automatic login after account creation doesn't really bother me too much. The only reason it's not commonly used is that websites typically like to verify the email address in the case of an account needing to be reset, if you don't have a verified email, how can they do that reliably?

The bit of them sending you a password in plain text, is a very bad idea for a couple of reasons.  First, if they send you the email with a password in it, it is very possible that that password can be compromised by a mitm as email is not encrypted by default.  Second, if they are sending you the password, it is likely that they have stored it in plain text.  Normally it is a bad idea to store passwords in plain text because people reuse passwords and when one site is broken into, the attacker can access all the other sites that password is used in. In this case I would think it would be less likely that the password you get assigned is something you would use with another site, but still possible (obviously don't do this).

If you can't change the password, I would not trust the website. If you can change the password, I would still be a bit skeptical.


Is shadow-stack using for anti-BufferOverflows only? I have some questions about shadow stack conception:

Is shadow-stack conception used for bufferoverflows preventions
only?
Is stack-canary adjacent with shadow-stack?
What will happen if return addresses of stack and shadow-stack do not match(is
shadow-stack has higher priority or sigfault will raised)?

Intel CET protects against Return Oriented Programming, not buffer overflows per se. Its job is to make sure that each RET instruction returns to the same address that its corresponding CALL instruction came from, and that's it. To do this, the hardware maintains a memory section called the "shadow stack" that is out of reach of the program itself. Each CALL instruction pushes the appropriate return address onto the shadow stack, and each RET pops the top value off the shadow stack and crashes the process if that value is not equal to the return value on the actual stack.

Return Oriented Programming is a way to get around DEP (or NX) technology. Since with DEP you can't just inject executable code any more, you can instead use ROP to overwrite return addresses and string together fragments of the program's own code in an order that makes it do your bidding.

Buffer overflows are used to inject payloads into a process's memory space, and those payloads can certainly be ROP payloads. But there's no fundamental relation between buffer overflows and Intel CET.


Is saving passwords in Chrome as safe as using LastPass if you leave it signed in? Justin Schuh defended Google's reasoning in the wake of this post detailing the "discovery" (sic) that passwords saved in the Chrome password manager can be viewed in plaintext. Let me just directly quote him:

  I'm the Chrome browser security tech lead, so it might help if I
  explain our reasoning here. The only strong permission boundary for
  your password storage is the OS user account. So, Chrome uses whatever
  encrypted storage the system provides to keep your passwords safe for
  a locked account. Beyond that, however, we've found that boundaries
  within the OS user account just aren't reliable, and are mostly just
  theater.

  Consider the case of someone malicious getting access to your account.
  Said bad guy can dump all your session cookies, grab your history,
  install malicious extension to intercept all your browsing activity,
  or install OS user account level monitoring software. My point is that
  once the bad guy got access to your account the game was lost, because
  there are just too many vectors for him to get what he wants.

  We've also been repeatedly asked why we don't just support a master
  password or something similar, even if we don't believe it works.
  We've debated it over and over again, but the conclusion we always
  come to is that we don't want to provide users with a false sense of
  security, and encourage risky behavior. We want to be very clear that
  when you grant someone access to your OS user account, that they can
  get at everything. Because in effect, that's really what they get.

I've been using LastPass under the assumption that it is better and safer than using Chrome's built-in password manager. There are two additional facts that are relevant here:

LastPass has an option to stay signed in on a trusted computer. Let's assume I use it.
Chrome lets you create a separate password for Google's synced data (read: stored passwords). Let's assume I do this as well.

With those givens, all other things being equal, is LastPass any safer than Chrome? It seems like once malicious software gets on my system, or a bad guy has access, it doesn't matter from a theoretical perspective, I'm 100% compromised. Is that true?

Also, from a practical perspective, is one or the other more likely to be hacked in real life? Are there certain attack vectors which are more common or more successful that would work one one of these or not the other?

PS: I don't care about friends, family or novices gaining access to my account. I'm asking about intelligent malicious hackers.

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.


The brute-force resistence of bcrypt versus MD5 for password hashing? Can anyone give me an idea? Assume the salt(s) is/are known.

For example, if I have a $k$-character long password that is hashed in MD5 versus bcrypt, is there a way to estimate how much more time it would take to brute-force in bcrypt versus MD5?

I know this is a vague question that depends on many factors, but feel free to assume whatever factors you want. Just looking to get an intuitive feel of the differences.

Bcrypt use a configurable iteration count, so the answer to your question is: whatever you want it to be.

If the iteration count is such that one bcrypt invocation is as expensive as 10 computations of MD5, then brute-forcing the password will be 10 times more expensive with bcrypt than with MD5.

If the iteration count is such that one bcrypt invocation is as expensive as 10 millions of computations of MD5, then brute-forcing the password will be 10 million times more expensive with bcrypt than with MD5.

That's the point of having configurable slowness: you can make the function as slow as you wish. Or, more accurately, as slow as you can tolerate: indeed, a slow function is slow for everybody, attacker and defender alike.

An additional factor is that bcrypt is, by nature, quite hostile to GPU optimization; this is due to the kind of operations that are used within the algorithm. MD5 is, by comparison, very easy to implement and run efficiently on a GPU. This means that an attacker may get a substantial boost out of a GPU when cracking MD5-protected passwords; while with bcrypt he will need to use the same kind of CPU as the defender. See this answer for further details.

If we want some realistic figures: with a good GPU (off-the-shelf, a few hundreds of dollars), MD5 speed can reach, say, 10 billion instances per second (see benchmarks there; the machine which goes up to 93 billions per second contains 8 GPU). However, with bcrypt, it would be customary to crank up the iteration count so that each hashing takes 0.1s on your server. Instead of buying a GPU, the attacker will buy (or rent) a couple multi-core CPU and will be able to try, say, 100 passwords per second. With these figures, one can say that bcrypt will make the passwords 100 million times more robust than MD5.


OpenVPN and running other services on same server What security implications should I know about/look for when running OpenVPN on the same server as my network cloud controller and apt-cache-ng?

I plan on using the same server to run apt-cacher-ng to cache updates for other Linux servers on the network. It will also run my cloud network controller (manages my switches, WAPs, etc).

Since OpenVPN requires opening up a port-forward on the router to the server, does this pose a bigger threat or am I over-thinking things?

I do not want to put apt-cacher on another system. The other possibility is virtualization but I'm not familiar with KVM or other Linux virtualization software. I don't run MS, so Hyper-V is out. And ESXi 6/6U1 gives me disk errors on Debian 8 due to the newer kernel not supporting WRITE SAME.

One issue is that if there are any services which are only accessible from the server's IP, including services accessible from the LAN (like your router's admin page) or even other services running locally on the server which are only accessible to localhost, then a user successfully logged into the VPN may be able to access them.

If you have any services like this (like your router's admin page) that you don't want VPN users to be able to access, then make sure they're securely protected by passwords and don't just rely on the inability of outsiders to connect to them.


How to eavesdrop and decrypt the HTTPs communication of an IoT device? I am trying to setup a MitM scenario between an IoT device and WAN. It is possible and quite easy to achieve same thing for the application run on a mobile device by setting my proxy server(Fiddler)'s certificate is trusted.

Since the IoT device that is being tested does not let you to make it consider the certificate as trusted, I am looking for the alternative methods. Is there any way to break in HTTPs connection and see all content as plain-text?

You basically want to break HTTPS.

There are a few ways this could work, but you are mostly relying on mistakes somewhere along the way. This is not an exhaustive list.

Device side problems

Device might check the certificate is signed by a trusted CA (your MITM proxy can just generate a certificate).
Device might check the certificate is signed by a trusted CA, but forgets to check CN (domain name) field, so any valid certificate works.
Device allows you to install a custom CA (same as you do on your mobile device).
sslstrip type attacks where device initiates connections on HTTP and relies on server to upgrade to HTTPS.
Downgrade attacks to less/in-secure encryption.
Modifying firmware to work with your certificates.

Target domain

Private key may be available (probably not, but has been seen before, more common for self-signed certificates).
Any compromised or misconfigured CA could be used to generate valid certificates for all domains (trusting all these CAs is the big problem of PKI).
Target website or DNS attacks would allow attackers to generate valid certificates.

(Un)fortunately this is quite hard to do when properly configured. If it was easy, there wouldn't be much point to HTTPS.


Triggering Javascript by user-agent string. CSRF or XSS? I've read several PHP-security books, but after reading one I got confused about the definition of a CSRF (Cross-Site Request Forgery). Wikipedia explains it as this:

  Unlike cross-site scripting (XSS), which exploits the trust a user has
  for a particular site, CSRF exploits the trust that a site has in a
  user's browser.

Normally this exploits goes about sending two requests, one for getting a token, and one for getting a token to reset e.g an administrator account. By example exploiting the vulnerability where a website generates weak entropy tokens by using e.g mt_srand(). Right?

But what if a website logs which browser you're using by collecting it's user_agent string?
E.g:
AdminPanel.php:

<?php
    $browser = $_SERVER['HTTP_USER_AGENT'];
    addToLog($browser);

    $logs = getAllLogs();
    echo $logs;
?>

Normally this'd return:
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0

But I could edit my user-agent string in Firefox:

+----------------------------+----------+--------+-----------------------------------------------------------------------------------------------------+
| general.useragent.override | user set | string | <script>window.location.replace('http://myHackerServer.com/fakeAdminPageForPhishing.php');</script> |
+----------------------------+----------+--------+-----------------------------------------------------------------------------------------------------+

This way the Javascript code would be executed on the Admin-panel.
So this way, you can exploit the XSS when the administrator logs the user-strings of users, and than checks it later.

But is this XSS or CSRF? I mean, the website does trust the user's browser to contain valid values. Like Wikipedia says. It doesn't necessary trust 'user-input' like in XSS. I got confused by what CSRF is, I've seen loads of different definitions.

Thanks.

Your example is XSS.
The full definition of CSRF from Wikipedia:

  Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

Example of a CSRF attack:
let's say you own a website example.com, and you have a shop where users can buy items using GET requests. An example link would be: example.com/shop/purchase?itemId=123456, and it doesn't perform any authentication but making sure the user is online. You land on the page - Boom, $30 are withdrawn from your bank account.

Now, an attacker could take that link and mask it inside an email, or by embedding it into a clickable image on an active forum - thus making it appear safe (click here to read more, etc). When a user clicks that link (who does not want to buy that item) - he's automatically charged the $30 which he didn't even want to spend!

The protection against this is fairly simple - You generate a unique CSRF token for every user when his session is created, and force him to pass the token as a parameter. So now your link is example.com/shop/purchase?itemId=123456&token=abcdefg. Now, an attacker can't send me "malicious" links - because he doesn't know my token!

As you can see, this attack really has nothing to do with Javascript. Your example was persistent XSS (an interesting topic by itself, albeit unrelated to your question so I won't dive into it here)


Re-display password in registration form good or bad? When a user tries to register and the data he submits are not right such as bad email, or weak password, we would display the registration page again to him with the data he just submitted along with the error messages.

My question is should we display the password he just submitted in HTML as this?

<input type="password" value="s0me7Xpwd">

Or just leave it blank and annoys him to enter another one?

It's definitely better in user experience to insert the password again (especially when the password is all right) but would it be good with regards to security?

This is not a problem in itself, but in my opinion a web application should implement the policy that passwords are only input, never output. Following this policy will result in a much more secure system as far as handling passwords is concerned.

If you are going to do this, then make sure you set the appropriate headers to prevent caching in the browser or in any proxy servers en route:

Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0

Note that the password will still be visible if view source is clicked in the user's browser. This is an additional, although very low risk as a normal user is unlikely to do this. The only time I could think the password might "escape" this way is if the user decides to save the page HTML locally using their browser's save page functionality.

You could store the password in session once it has validated against any password requirement policy and matches the confirmation. Then you could simply include some code to suppress output of the password fields if the password has already been accepted by your application. The downside to this approach is that passwords are held in memory for longer than otherwise necessary, which means your application is at a slightly higher risk of memory attacks. Heartbleed was one - of course you need the vulnerability to exist in the first place for the risk of exposure to increase in this way. One way to mitigate this is to hash the password ASAP and store the hash and salt in memory.

If you want to allow the user the option of changing their password, you could output a field with a "magic value" rather than the password itself.

<input type="password" value="notrealpassword">

Then you simply detect whether the user subsequently edits this field to know whether to update the password stored in session.


Can worms delete your network? A few nights ago, our network wifi had somehow gotten deleted, resetting it to its default network name. Can a worm delete your network wifi? Not saying that is what happened but it was a thought that started running through my head.

So your SSID was reset to its default name, and you're asking if a Malware could be responsible.

Yes, it is possible. Searching on the web if your Router model is vulnerable will help you. Most of the makers patch those kinds of flaw by Making some new firmware version. Keeping the router firmware up to date is a good habit.

Not in the question scope

If this WIFI Router is your ISP property, please call them. They may have scheduled a global factory reset for some reason. (Which is pretty rare)

Make sure you do not use WEP encryption. Exploiting a weak encryption scheme is one of the most popular ways for hijacking a WIFI network.

If you cannot figure out why your Wifi Router has been reset to its default configuration, it might have been compromised.


What is a next generation IDS? Intrusion detection has been there for many years. It monitors network traffic and/or system events like sys calls or other data and determines whether an event is intrusion or not.

But I am curious what has a next generation IDS in addition to a classic one?

Next generation is just marketing lingo and "IDS" itself too, as do IPS, NGFW, UTM and whatever they come up with next week. The underlying technologies got several enhancements in the past, e.g. they can look deeper, may use anomaly detection etc - but in my opinion they are still dumb enough and can still be circumvented with not too much efforts.

Don't let you blend from all the marketing claims about 100s or 1000s of applications they can detect or how fast they are and how secure they are. They give you some protection, but not the advertised one.

And in case you don't believe me but the marketing guys you can read here:

"Evading Deep Packet Inspection for Fun and Shell" (BlackHat 2013): https://media.blackhat.com/us-13/US-13-Opi-Evading-Deep-Inspection-for-Fun-and-Shell-WP.pdf
Circumventing security systems with uncommon HTTP: http://noxxi.de/research.html (disclaimer: that's my research)
NSS Labs Report from 02/2013, where you can see how far claimed performance and security differs from the real world: https://www.nsslabs.com/reports/2013-firewall-comparative-analysis-tco


generating RSA keys through the browser HTML5 has the  element that sends an SPKAC to the server (as I understand it).

But how do you do it in IE?

One CA's websites gives me the following prompt:

This Web site is attempting to perform a digital certificate operation on your behalf:

https://www.startssl.com/

You should only allow known Web sites to perform digital certificate operations on your behalf.
Do you want to allow this operation?

That's cool and all but how do they do it and how do I make it so a website of mine can generate private keys for people? IE doesn't support the keygen element.

With Internet Explorer, for this kind of job, you are supposed to use the CertEnroll API (in pre-Vista Windows, this was called XEnroll); it can be used from Javascript. This implies Javascript to detect the type of browser.
Microsoft says that lack of support for <keygen> is "by design".


Public web server and AD- based Kerberos authentication I would want to use SPNEGO/Kerberos protocol on a public internet webserver for specific remote ip addresses coming from corporate intranet. Other authentications methods are used for other addresses (Form- based login/password). All I want is to get the domain username of the incoming user if they are coming from corporate network. I'm using keytab file on the webserver created with ktpass. Webserver is in DMZ and isolated from intranet. The Kerberos implementation in question is Active Directory.

Is Kerberos suitable for public internet webserver authentication in this kind of setup?
Are there some specific security considerations related to a setup like this?
What are the necessary steps if the keytab file gets compromised?

I don't see any immediate weaknesses.  Kerberos is going to look for the user to supply an access token generated by the Kerberos server which should only be available on your private network.  The web server shouldn't know how to generate an access token that would allow access to the private network so all that could be done by compromising the service shared key of the web server would be to allow access to the webserver (which presumably the attacker already has access if they've compromised your service secret key.)

In fact, I don't believe the web server should even need access to the Kerberos server since it only needs to be able to verify a TGT which only requires knowledge of the service secret key.  The client that is logged in to the private network should be the only one with a connection to both worlds.


Can a deleted PGP secret key be recovered from private-keys-v1.d directory? Executing gpg -K --with-keygrip returns one key entry. However the private-keys-v1.d directory has two entries. I assume that one of them belongs to a secret key that has been deleted/removed.

Is there any way of restoring a secret key from this directory?

The question is based on the wrong assumption that for each PGP pair there is one and only one entry in the private-keys-v1.d directory. The private-keys-v1.d directory comprises the key store of the gpg-agent so apart from the private keys used by gpg there may exist other keys used by SSH or X.509 or secret subkeys.

Deleted keys are not going to be present in this directory. On the other hand if you have at hand the private-keys-v1.d directory it is possible to restore the keys as explained here.


What does it mean when Reaver returns a PIN but no passphrase? Usually when it's done, the WPA passphrase/password is listed immediately below the WPS PIN.

Any idea what it means when it's absent from the results?

I also tried entering the PIN directly, using the -p(--pin=) flags to no avail. Here's what it looks like:

FYI: I'm using the (green) Alfa AWUS036NH; with which I've had much success in the past. It uses the Ralink RT3070 chipset.

This usually happens if the router has the PBC (Push Button Connect) activated. The wps pin is the correct but then you can't get the password. So you'll need to push physically the button on router.

Sometimes this behavior can be because a bad signal. You can try closer to the AP.

Other times it depends of the compatibility of your chipsed and the software. For example, if you have a Ralink chipset on your wireless card, Reaver doesn't work very well. If this is your case you can use the alternative to reaver (bully).

EDIT:

Another idea... Did you tried using -N (--no-nacks) parameter?

EDIT2

I found this, maybe it can help you: https://gitlab.com/billhibadb/reaver-wps/issues/203


Passing plain text password over HTTPS My login for POST is over HTTPS. Therefore, I don't do anything to the provided password before submitting. And I don't see an issue there unless someone is watching your browser's developer console. (Tested the Google login. They also share the same approach.)
But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?

Passing plain text passwords over HTTPS is absolutely fine. TLS makes sure it's not plaintext on the wire, so there is no issue. Client side hashing would do nothing to help here. The fact that you can get the password from the development console is expected and not an issue.
As for the concern about session hijacking, I don't get it at all. If an attacker that has hijacked a session could somehow get your password I would view that as a problem since it would allow an attacker to go from temporary access to permanent access. But sending your password untouched over HTTPS would on itself not lead to that. I think that either the person that told you this is misunderstanding something, or you misunderstood the concern. Is it perhaps related to some other wider issue?
Finally, a side note. You write that your "login for POST is over HTTPS". Are you using HTTPS just for the login? That is not enough. Your entire site - absolutely everything - needs to be over HTTPS. Just protecting the login endpoint makes you vulnerable to SSL-strip. If you use plain HTTP without TLS for parts of your website, you need to fix that.


Clamav can't detect encoded virus files I have a PHP sheller file (like c99 file) but it's encoded with this functions:

eval(gzinflate(base64_decode("7P3rehblahblah"))

The clamav virus scan can't detect it. How can I detect a virus and sheller like that?

ClamAV is possibly not the correct product to identify php shells. This is because there are endless ways to encode the shell, and it is not tailored to understand PHP code.

There are other technologies that are more tailored to detect malicious php code.
Emphosha is one alternative that understand the php preprocessor, and can raise warning based on functions considered used for obfuscating code + able to detect known shells.


exponent value in certificates I have seen that in gmail, there are 3 certificates in hierarchy. I noticed that all the certificates have the same exponent(65537 with 24bits). Why is the exponent value same for all certificates and how?

This is a common trick to speed up encryption and verification. The exponent is special, in that, it is a small prime number with only two bits set, which makes modular exponentiation in software fast enough. Another commonly used public exponent is 3, but I think that one is falling out of favour these days.

See this question for some more information on the security of these special exponents.

As for the "how" of these exponents, since the modulus is a randomly generated (within some constraints, of course), the private key is still random, and cannot be determined from the public exponent and modulus alone.

The reason why we want as few bits in the exponent as possible is the way modular exponentiation is done. When you are calculating the modular exponentiation using the public key, you only have two numbers: the public exponent, e, and the modulus, n. For private keys, we can can have some more information (actually the prime factors of n) to speed up calculations (you can look up "Chinese remainder Theorem" for RSA if you are interested), but obviously these prime factors cannot be distributed along with the public key. So, we are left with the standard square and multiply algorithm.

The main idea of the algorithm is to square the message for each bit of your exponent, and multiply it to an accumulator when the corresponding bit in the exponent is set. Say, you want to calculate m13. You first write it as a multiplication of a series of m2j, i.e. m23·m22·m20. Set a variable to m, and result to 1. Now, start counting from 0 to 3 (the maximum bit length of modulus). For each value, if 13 has the bit position at counter set, multiply your result with the variable. Before increasing your counter, square your variable. With this scheme, you'll calculate m, m2, m4 and m8 at each iteration of your loop from squaring your variable. When a bit is set in exponent, you pick the value, and multiply it with your result to get m·m2·m8 (which is m13). For a random 1024 bit key, you'll need to call sqrmod(m, n) 1024 times, and also mulmod(accumulator, m, n) roughly 512 times (the bits are random, so we only know it is less than 1024, and 512 on average).

When you have a small exponent with only two bits set, say 65537, you need to square only 16 times, and multiply only once (m2k can be calculated by initializing a value to m, and repeatedly squaring it k times, and m65537 = m216·m). It is even faster when exponent is 3: you square once, and multiply once.


How does AES-GCM handle large blocks with a 128 bit key? I would like to apply AES-128 byte encryption on GCM mode. I know the logic to apply AES_GCM using 128 bit data. But I have a larger data to encrypt (Not necessarily multiple of 16 bytes). As the AES-GCM is encryption is performed by XORing that key stream with the data to encrypt.

Is it possible to merge encrypted blocks in the order to get the final encrypted data?

As XOR is performing on bit wise there is no padding is requred if total data size is not a multiple of 16 bytes?

How to generate authentication tag in AES-GCM mode?

I could not find any information regarding this. Please help me.

AES-GCM, like all versions of AES, has a block-size of 128 bits, or 16 bytes. Generally speaking, you shouldn't have to worry about the "merging encrypted blocks" as the implementation should handle encryption of data larger than a single block for you, and simply provide you with the full ciphertext that is the end result.

Likewise, you don't have to worry about generating the authentication tag.  The implementation generates the authentication tag for you. and you simply need to retrieve it once encryption is complete.

More Technically:

AES-GCM is a combination of AES-CTR and a authentication tag computed using Galois field multiplication.   The fact that it is based on counter (CTR) mode which is a streaming mode means that the ciphertext is of variable length.  The output can be the same length as the plaintext input, and does not need to be padded to make a full 16 byte final block as block modes such as ECB or CBC would require.  The authentication function is a keyed hash function computed over both the ciphertext, and an additional authentication (but not encrypted) data which will always include (at minimum) the nonce.


Malware getting root access via "sudo" and "sudo -s" Actually, I'd like to ask 3 questions. But since they are very related, I'll ask them all here. I use Ubuntu 12.04.4.

Situation 1: I use Terminator, in one of its terminals I launch sudo iotop (because it doesn't work without root access). Question is: can a malware gain root privileges via a process that is run with use of sudo , and how?

Situation 2: I open tty1 (Ctrl+Alt+F1) and type sudo -s there, thus gaining the root privileges. Without exiting this sudo shell, I may go back to my graphical interface (Ctrl+Alt+F7) and work as an unprivileged user. Question is: can a malware abuse this sudo root shell in tty1 console to gain root privileges?

Situation 3: I run sudo -s in a Gnome Terminal. Can this shell be abused by a malware to gain root access? Here, I have a presumption, that it can abuse some input functions to activate terminal's window and type a command in terminal, but not sure.

It depends on where the malware resides. Let's assume you mean : some program running as your user and wanting to get privileges.

Really short X security primer

First, you have to be aware that X does some access control but does not isolate between connected clients. Every client connected to your desktop can query the server to obtain information about any other X client and interact with it.

For example, if you run Skype (or whatever program, open-source or not) on your desktop, it can spy activity : list windows, their titles, take screenshots, log keypresses, even (with some graphical toolkits) figure out the structure of what it's currently displaying. So in theory it can locate if you have a terminal with a root shell opened, send keypresses events to type something there (though not all terminal emulators obey these).

In practice simulating keypresses may be noticed by you (you see that something happened, or maybe the program could just close the window after doing the job to hide it), while plain keylogging is invisible (especially) if the program is authorized to communicate with the outside world through an encrypted connection (instant messaging, audio and video programs for example, that includes Skype, Google Talk, Flash and other plugins).

Reference: The Invisible Things Lab's blog: The Linux Security Circus: On GUI isolation

Answers to your questions.

In situation 1, you basically trust iotop but I guess that's not your point.  Let's imagine a malware connected to your desktop or running as your user. It could try to trick iotop into doing something nasty (by simulating keypresses, etc.) but it would probable be ineffective.

In situation 2, the shell is separated from X, so it's better security-wise.  You have to know that one program running with your user account can write on a Linux virtual console where you're logged in, but it's only inserting characters on the screen, not process activity.  AFAIK you can't trick a program into actually typing something into another Linux virtual console.

Situation 3 is what's explained above.  A program could notice that, type some commands and try to hide the fact.

If you're really concerned, you are probably interested in security by isolation and Qubes.


Suspicious 'upstream' traffic We are seeing unusual amounts of traffic heading upstream on our WAN connection, during the day our system can exceed (or attempt to exceed) the 1Mbps limit imposed on the connection.

I have PRTG netmon which gives the figures but cannot identify where is going from/to (or the actual protocol which is 'other').

How can I identify this traffic? Where should my port sniffer be connected?

VM/Windows based network → Sonicwall TZ170 firewall → Speedtouch DSL modem → Demon Internet

In order to trace back the source you first need to figure out which device is generating the traffic. The best, in my opinion, would be to set up a flow collector of some sort. There are generally two ways to do this,

Exporting flows from the device
Software analysis to generate flows

Most high end network gear will generate some kind of flow record, such as sFlow, jFlow, or NetFlow. These are produced directly by the router and sent to a collector. You'll then use some kind of analysis tool like flow-tools or nfsen/nfdump to process the records.

Using other devices will involve getting a copy of all the traffic somehow, typically using a tap or setting up a mirror/span/monitor port on you border device. A tap is a physical device that you place inline with a connection and it will electrically duplicate the signals. The mirror port is configured on the network device itself and will send a copy of all packets from one switch port to another. Most "enterprise grade" devices support this, but for lower grade equipment a tap may be required.

Once you have a copy of the data you'll need something that will take the traffic stream and turn it into flow records. There are a number of commercial products, but I am most familiar with the open source product Argus, produced by Qosient. It will process the packets on an interface, much like tcpdump, and produce data files that consist of flow records.

Whether you go with exporting flows, commercial products, or Argus you now have everything you'll need for your analysis. Any of those collection tools will contain all the necessary tools to produce bandwidth reports like you want. Or just about any kind of report you want, really.

I'm sure this sounds like a massive overkill, but the results are fantastic. These types of records are invaluable for network troubleshooting, incident response, forensics, billing, etc.


RFID blocker with a card There is a company out there that developed a product which looks like a simple card ( format of a credit card or so ) and claims to block rfid-signals in a distance of 10mm. It is not a case to protect a card but rather card which you put over the card/cards you want to protect. Is this actually possible or is that a fraud?

I am not talking about two cards blocking rfid signals like in this example but one card that can block anything in a distance of 10mm. Is this possible and if it is can you provide me a trusted source for this?

Are you wondering if such technology exist, or are you wondering if the speech of a company you know but for some reason do not mention is realistic from a technical point of view?

No matter what, such company exist, an example would be Amourcard. I do not know if there are other, they claim to be the first to offer such service.

This company targets more specially the NFC world, which is subset of RFID used mainly for credit card and passport:

  Armourcard electronically jams the frequency these credit cards &
  epassports communicate over (13.56MHz)

NFC technology does not cope with noisy environment. I mean that if the communication frequency is full of garbage information, the communication between the NFC reader and the tag will not be possible.

This card goal is therefore to produce such garbage information. Internally it is most probably exactly the same kind of circuit you may find in NFC enabled credit card, but instead of implementing the NFC communication standard it just endlessly send garbage as soon as an NFC reader tries to communicate (by the way, on their OOperating Instruction page, section 'Tap & Go' payment gateways, they acknowledge that this behavior may lead several readers to crash and reboot).

At least in principle, this should effectively work for the designed purpose, which is protecting NFC enabled credit cards and passports, as long as this jammer card is stored together with them,
It may be less efficient with other kind of RFID tags, even if they operate on the same frequency, due to protocol or technical differences,
It will not be effective at all with RFID tags operating on different frequencies than 13.56MHz.

Quick addendum: while browsing the site of the aforementioned company, I see that they made the choice for their jammer card to embed its own battery instead of relying on the NFC reader signal like classical NFC tags. They announce a battery life within 18-24 month. Be sure to check the battery status regularly (a green led lightning up when you temporarily disable the jamming feature by holding your finger on a small "button" on the card), since when the battery deplates you will not be protected anymore maybe without noticing it (the card needs to be replaced by new one, no way to replace it).


What is the proper terminology for the various SMTP tunnel encryption solutions? I'm writing up documentation and want to ensure that I'm using proper terminology.

1) What is the proper technical term for the SMTP tunnel encryption standard that typically starts on TCP/25, involves checking ESMTP capabilities for 250-STARTTLS and issuing the STARTTLS command (followed by negotiation, public cert exchange, etc)?

2) Likewise, what is the proper technical term for SMTP tunnel encryption that uses port TCP/465 and requires negotiation immediately

I've always just called #1 "TLS Encryption"/"TLS" and #2 "Secure SMTP"/"SMTPS" but I don't think that's accurate.

I've mostly seen the first case referred to as "SMTP with STARTTLS" and the 2nd as "SMTPS".  The first case is defined by RFC3207 which has the name "SMTP Service Extension for Secure SMTP over Transport Layer Security," but that's too much of a mouthful for use in documentation.  I've also seen "the STARTTLS extension" when the rest of the context makes it clear that SMTP is being discussed.


Is it a good idea to combine words from different languages to increase a password's strength? I was thinking of a way to generate a password that is easy to remember, but hard to crack, like the famous "correct horse battery staple" suggested by XKCD, also discussed here, and I've realized I've never heard the suggestion to combine words from different languages. Other questions on this site deal with non-English passwords or dictionaries, but they don't consider mixing languages, which is what I am focusing on.

Let's make an example. My native language is Italian. If I translated the last two words and came up with "correct horse batteria graffetta", wouldn't it be a lot harder to crack than the English sentence?

Lots of people have at least basic knowledge of a second language, so it should be easy for them to choose a foreign word. Granted, if their level is low, they are likely to choose very simple words (like "hello", "cat", "dog") which would be easy to guess, and this would be bad. But excluding this case, that is, assuming the chosen words are not completely trivial, would this suggestion work? Would it provide stronger passwords, all else being equal (that is: the total length, the presence of lowercase/uppercase letters, numbers, and other symbols, the entropy...)?

In my opinion the effectiveness of this strategy depends on the attack. If it is purely brute-force (i.e. no dictionary), I'd say it's the same. But if the attack is dictionary-based (as is likely the case), wouldn't this technique thwart many attacks? How many dictionaries are there that combine words from more than one language? I think my example phrase "correct horse batteria graffetta" would be quite hard to guess.

Let's take this approach even further and add one more language. "Horse" in Italian is "cavallo", and in German it's "Pferd" (with capital P, but let's ignore this and keep everything lowercase). Wouldn't "horse cavallo pferd" be even harder? And this is just one word translated in 3 languages, which is probably a very bad idea. Let's take 3 unrelated words: window, shark, apricot. What about "window squalo aprikose"? I think this would be really hard to guess.

Of course, this is "security through obscurity", that is, this method works well if the attacker doesn't know that it is being used. Let's assume the worst case: he is aware of this, and he even knows what languages I speak. Clearly my idea would be mostly ineffective in this case, but still: wouldn't it be better than choosing words from a single language? The attacker would be forced to use a larger dictionary, and his attacks would take longer.

To conclude: I think creating a password by combining words from different languages can greatly reduce the effectiveness of a non-targeted dictionary attack (and possibly thwart it completely). If, instead, the attack is targeted, the benefit is smaller, but on the other hand there is no drawback. Therefore, this method can be seen as an improvement over XKCD's suggestion.

Am I right? Is it a good idea to adopt/recommend this technique, or am I missing something?

All that matters when calculating the strength of password generation strategy is how much entropy is involved in the generation of the password.

Using multiple dictionaries does not weaken the pass phrase. How much this strengthen the pass phrase through, depends on how exactly you choose your pass phrase.

From the perspective of calculating entropy, using a combined dictionary from multiple languages is exactly the same as increasing the number of words in your dictionary.

For example, standard diceware strategy used a dictionary with 7776 words. The strength of a 4 words diceware password is 7776^4 ≈ 2^51.7, or 51-bit. If you modified this strategy so you use a combined dictionary of 7776 English words and 7776 a Italian words, then the strength of your passphrase would be (7776+7776)^4 ≈ 2^55.7, or 55-bit, which is just 4-bit stronger than the standard diceware.

If on the other hand you decided that the first two words is going to be English and the last two words is going to be Italian, or if you decide you're going to use a combined dictionary of 3888 English words and 3888 Italian words, then these do not actually increase the strength of the passphrase from entropy perspective.

Generally, it's more fruitful to increase the number of words on the passphrase rather than increase the size if the dictionary. If you used 5 words standard dice ware passphrase, the strength of your password is 7666^5 ≈ 2^64.6, which is a nearly 13-bit increase from 4-words diceware. To get a 13-bit increase in strength by increasing the dictionary size from 7776, you need to use a dictionary that is 9 times the size of standard diceware dictionary (9*7776)^4 ≈ 2^64.4 (i.e. You need to use 9 languages).

It wouldn't hurt to increase the size of the dictionary, but it doesn't really add much entropy. From entropy perspective though, passphrase length matters more than the size of the dictionary.


how to deal with passwords When implementing a login / password checking mechanism, should one check if a given password is already in use (I'm aware that knowing that a given password is already in use presents a risk of brute force attempts ) or should we perhaps warn the administrator that a particular weak password is used quit often by users ?

When implementing a login / password checking mechanism, should one check if a given password is already in use

No. Actually you should be following a slightly different rule: when implementing a login / password checking mechanism, one should not be able to recover passwords, only verify them.

To achieve this, here is what you need to do:

Pick a slow password hashing function. Argon2 would be ideal, If you cannot use this (or wish to make a more conservative choice) then choose one of bcrypt or PBKDF2.
Generate a random, unique salt per user (it should be unique per user, this is important).
Apply the hash function you have chosen to the password+salt, as described in its documentation. Usually this will simply be H(salt||password) or H(password||salt), but follow the documentation for the function you choose.
Store the result and the salt in your database, alongside the user identifier.

Pepper has just been mentioned in comments. You can also generate a global load of random junk for your site and hash your passwords like this: H(pepper||salt||password). Store both the pepper and the salt. Pepper buys you further resistance against any kind of rainbow table attack and further resistance against any kind of brute force attack. See Password Hashing add salt + pepper or is salt enough?

To verify any password, you simply repeat this process with the submitted password. At the end, the result should be the same, if it is not, fail the login.

What this buys you:

If your database is stolen, rainbow tables will not work (thanks to the salt).
If your database is stolen, bruteforcing will take a very long time (thanks to the slow hash function).
If your database is stolen, there is no easier way than brute force, thanks to the fact you are using a hash function and not secret-key encryption. You should assume that if your database can be stolen, so can your secret key for decrypting your passwords.

For improving password quality, you could reject certain passwords. For example:

Set a minimum password length of of a decent amount. Some will say 8 characters; personally I would err on the side of caution and say 12 characters.
Do not set an upper limit, or set a reasonable one such as 63 characters. Users who use 32 character passwords of randomly generated printable ascii are helping themselves massively and you should not arbitrarily stop them or get in the way of password manager usage.
Require some reasonable combinations of letters, numbers and punctuation. When setting any complexity requirements, first read this answer.
Do not set an regular password expiry. This will encourage all manner of bad behaviour in users, for very little benefit.
Encourage better passwords with a "password quality" meter.

To improve the overall security of your system, consider implementing two-factor authentication for accounts. Yubikeys (U2F) are inexpensive and straightforward for users of Google Chrome (and maybe soon Firefox); TOTP is also good. SMS authentication is considered dubious due to the vulnerability of mobile networks to tampering with and intercepting SMS delivery.


How to secure email validation endpoint? We have email validation in our registration form (an Ajax call to a REST endpoint to validate an email address when a user enters it).
Lets say a normal form first name, Last name, Email, Password, Address...
We have 2 actions in this form.

When user enter an email we do a call to backend and check wether this email is already taken by somebody.
Form submit.

We do have a CSRF token(per one request in a hidden field) for the whole form(so we get a new token after email validation call).

But somebody can create a script to call to email validation endpoint with the token and collect the email addresses we have in the system.

Are there any good practices to secure this kind of scenario?
We also plan to implement throttling.

Edit to answer actual question

Sorry for misunderstanding your question. That being said, here is an answer.  If your goal is to make it so that no one knows what email addresses you have registered on the system (which is a good goal), then the simple answer is that you can't verify before hand if the email address is taken, and then let them know if so.  Regardless of what security measures you put in place, you will still have a place where people can come and ask "is this person on your site?".  Even rate limiting doesn't really do it, as a malicious attacker might be targeting a specific user.  If they already know the person's email address before hand they only have to go to your register form and see if the email is taken.  Instead, you are going to have to adjust your registration step:

You can always validate that it is an actual email address (telling them that the email address isn't an email address will protect against typos and obviously won't reveal anything sensitive).
Make them type the email address twice: this will, again, help prevent typos, which will be a big aid in the next step:
Force the user through an email validation process, like I outline below: send them an email with a key that they must use to activate their account.  This provides a couple layers of protection.  If someone is using your registration form to sniff for used email addresses, they won't find out anything.  In all cases your registration form returns a generic message "Please check your email for instructions on how to activate your account".  If the email address already exists then, rather than sending activation instructions, you can send a "You just tried to register but already exist in our system.  Click here to recover your password.  If you didn't try to register, please click this link and then disregard this message" (or something like that).  Otherwise, do the normal email validation message.

Since you don't want to tell people if they try to register with an email that already exists, you will get three different people who submit your registration form:

New people who are trying to register (these people will have no problem at all)
Old people who are already registered but forgot: your alternate email will help them get in very quickly.
People who are trying to scrape your email list.  They will get nothing at all.

As a result, malicious actors will be shut out and your legitimate users will get through without problem.  A good mix between usability and security (IMO).

previous answer: mildly applicable

Proper email validation shouldn't result in someone being able to check for the existence of email addresses in your system.  You may need to include more details about what exactly you are doing.  That being said, it's always worth explaining what the answer should be:

Email validation should be done by a cryptographically-secure and random key that is emailed to the user.  At that point in time validation can be as simple as clicking a link that you send to the user that looks something like:

https://example.com/verify_registration?key=LONGANDRANDOMSTRING

Things to keep in mind:

Make sure the validation key is generated with a proper CSPRNG: if the user can guess the key from their input, it is useless.
The user's email address is not part of the input and is not needed at any step in the validation process.  The fact that the user knows the random key, which is only handed out via email, is what verifies that the user owns the email address.  As a result, there should be no opportunity for people to scrape a list of email addresses.
Make sure that your key has enough random bytes that it can't feasibly be guessed
Normally you would only use POST requests for making changes, and therefore you want to make sure that this endpoint has CSRF protection.  However, that is not necessary here.  The reason is that the key itself is sufficiently random that no one but the person with the email should have it anyway.  So it's better to make the validation process happen via a simple link and GET request.  Even if the user just has to copy and paste the key from their email to a web form, someone will get it wrong.  The way this works is simple enough and secure enough that (IMO) a simpler UI is perfectly reasonable.
Worth mentioning because I see this all the time: hashes don't add randomness to a string.  Use an actual CSPRNG to make the random string.  Don't just take some otherwise simple data and hash it.  Hashes don't add entropy: they must make it look random.


Is there a way to verify a binary against the sources? It seems like there is no practical way to verify the full integrity path of precompiled and packaged software? I can check the downloaded package itself by hashes, but I have no verification if the compiled binaries really represent the public source code?

Is there not even a theoretical solution for this problem? In the best case a way that could be automated?

Maybe decompile it and compare the output or hashes of it with something the software provider offers?

Compilation is a mostly one-way operation, and it is not deterministic, at least not in a robust way.

You could recompile the source code and see if it yields the same binary. However, the exact binary can vary depending on a lot of parameters, including the compilation options and the exact version of the used compiler. Moreover, some compilers embed some "comments" in binary files, comments which usually include the compiler version but also may include the "build number" (if such a number is maintained) and, possibly, the build date and time -- in that case, you will not get the same binary, not down to the last byte. If you want to see if you got the "same" binary, you may thus have to first strip them of such comments (the Unix strip command may be useful).

Strictly speaking, compilation could be randomized; since generating optimal code is a hard problem, some compilers employ randomized algorithms which, heuristically, are good on average. Such a compiler could generate a distinct binary each time. Since such behaviour makes debugging much harder, many compilers who indulge in heuristic algorithms will still try to be reproducible (i.e. they will get their randomness from a PRNG seeded with a specific, configurable value).

There is a much simpler solution: if you have the source code and can recompile it, then just use the output of your recompilation.

Of course, this does not completely solves the problem of trust; it just moves it around. When compiling from source:

you have to trust that the source code does not contain backdoors;
you have to trust the compiler itself for not playing nasty tricks on you.

At least, source code is nominally readable by humans (that's the point of source code), so you could perform some analysis of the code by reading it (or having it read by some specialist that you trust). There is no known way to make sure that a given piece of code does not contain any backdoor or vulnerability (otherwise, this would mean that we known how to produce bug-free code); however, it is much harder to conceal a backdoor in source code than in a compiled binary.

As for the compiler, see this very classic article.


Phishing virus found on server I recently had a call from BELL concerning a virus on our Linux ( Debian ) Server. Apparently Google emailed our client about an Italian Database found on our server that was doing phishing. They asked Bell to block our IP if we couldn't find it within an hour.

The folder was called "Show" and inside it was an index.PHP and a bunch of other files. I deleted it and now it's fine.

The folder rights were root:root. I believe it was added when the site admin uploaded a file from his PC. But how would the file ownerships be root:root?

How do I prevent such problems. Is there any Linux packages that would help?

***In case its relevant the client is using phpMyFaq and the folder "Show" was inside the folder "Attachments".

P.s in my access.log I have a lot of these:

- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"

where XXX.XXX is a real IP...

Could it be related? After Googling these codes I always get something about SSL's.

First things first: you must (I insist, must) wipe out your hard disk and reinstall from scratch. Any half-witted attacker or mere virus which could gain root access on a system will certainly not stop after adding a folder. It is highly probable that one or several backdoors have been installed, in various system utilities and/or the kernel itself, in ways which you will not be able to detect from the machine itself. So backup data files, reinstall the system, and copy back the files only after a through verification (in particular PHP source files).

A SSL/TLS connection begins by a first message sent by the client, and beginning with a header whose three first bytes will have value 0x16, 0x03 and 0x01, in that order (assuming that the client implements TLS 1.0, which is the most common case). Your log lines look like someone tried to connect to your HTTP server as if it was a HTTPS server -- and your server, unable to make sense of the bytes sent by the client, responded with an appropriate HTTP error message (which the client probably did not understand either, since it was trying to establish a TLS connection, not to exchange HTTP messages). This is probably harmless and quite possibly fully unrelated to your intrusion issue.

To prevent any further intrusion, you must only use software which has no bug -- which is not possible with current earth-based technology. The closest you can get is to maintain your system up-to-date with known security fixes; you should check for security updates on a daily basis (with Debian, this is a matter of apt-get update && apt-get dist-upgrade).


Are digital signature algorithms subject to the same types of attack as public-key encryption algorithms? I understand that digital signatures are usually implemented by encrypting a message digest with a private key, decrypting the resulting signature with a public key, and verifying that the message digest matches the message. This seems to be a normal application of an asymmetric encryption algorithm rather than a different algorithm, but is there anything about the scheme that makes it vulnerable to additional classes of attack over and above those that the underlying asymmetric encryption algorithm might suffer?

For example, does the use of a message digest algorithm, or the presence of the plaintext message, provide any additional information that an attacker can use to defeat the scheme?

To clarify what I'm asking: public-key encryption might be defeated by attacks such as chosen plaintext, or a breakthrough in factoring large numbers. Does using a public-key encryption algorithm in a digital signature scheme enable any additional types of attack?

Does using a public-key encryption algorithm in a digital signature scheme enable any additional types of attack?

Yes.  Using PKE for a digital signature has additional attacks; e.g., if you are using an RSA signature there are collision attacks on the hash function where if you can construct two messages m and m' that both have the same hash (H(m) = H(m')), if you can legitimately get someone to sign message m, then you can append that signature to message m' (even if you could not legitimately get someone to sign message m').

For example, back in the day MD5 was used as a hash in SSL certificates (X.509 certificates).  However, it is possible to carefully construct MD5 collisions in much less than the expected 2^64 work.  Therefore, an attacker merely had to construct a collision between a valid certificate they created (for say a website they control) and an intermediate certificate authority (note they should not alter the modulus or exponent to construct the collision as they need the private key).  Then when you can get a trusted certificate authority to sign your valid certificate for the website, you can append that signature on to your fake intermediate certificate authority.  Voila!  You now have a trusted intermediate certificate authority and can sign any certificate you want and get web browsers to trust it.

This attack was successfully done in 2008.


Certificate Based Authentication with AD and 802.1x or EAP-TLS I like to think I have a better understanding of PKI then most people but this one issue has me scratching my head and I was hoping someone could cut to the core of it.

In a system where you have Wireless that is authenticating via certificates and not usernames/passwords, I am confused about the private key sharing across devices or if it even uses the private key for actual authentication.
For example, you have an Apple phone that you want to authenticate via a certificate that is managed by AD and some MDM. When the MDM pushes a certificate to the phone for the user, is the user's private key, assuming it is in AD, pushed to the phone as well?  I can see with EAP-TLS where you need to encrypt data so the private key is needed but for authentication it is just a matter of validating that the certificate is authentic and is that user's certificate, which to my understanding a certificate can do with or without a public/private key, right?  It appears that the client cert is actually doing double duty as the eap-tls cert for encryption and for authentication, since these seem to be tied together in most implementations the thought occurs that you could have a device specific cert that generated a unique private key to establish the tunnel and a user certificate just used to validate the user without exposing the user's private key to the mobile device.  Is this the case or is this normally how it is done and I am just missing that part in some of the explanations.

Lastly, I am not a big fan of certificates used for authentication as it seems to be more of a stored password on the device which can pose a lot of security questions.  If AD does share the private key for the user this seems to exacerbate the security issue by allowing all traffic and data to be exposed to that user if a single device is compromised.  Am I missing something with this that would make me feel better then I do about certificate-only based authentication?

Thank you

Maybe some of following statement are not accurate, but in overall, it works very similarly.

It really depends on implementation. But the idea is the private key never leaves the device it is using it. If so it is wrong design. I don't know any MDM (mobile device management software) as I didn't work with any previously but it will work in very similar way as I describe bellow.

The mobile device (iPhone in your case) will generate private key. It will also create the CSR (certificate signing request - it out of other data includes public part of the generated key), please note the CSR can also be generated by the MDM then delivered to iPhone for signing. Then iPhone signs it (hashes it and encrypts the hash) using the generated private key and send it over the MDM to CA (certification authority) for validation and approval. MDM is responsible for device authentication before the first key is generated, I would say you need to login using AD user name/password for the first time from trusted network without any authentication method, such as 802.1x.

Once the CA will ensure the validity of CSR (this can be also completely manual process) it creates the certificate and signs the certificate using its private key. It stores generated certificate to issued certificates store and passes it back to the MDM. MDM will store it in AD (or not) and send it back to the iPhone device. Once device receives the signed certificate it checks if it has appropriate CSR stored inside (it should as it generated / signed it), pairs the information from signed cert and CSR together and store the certificate including the public and private parts of the key internally (usually to secure certificate store). Private key can be additionally protected using some kind of another protection (i.e. PIN, password, smart card, whatever) so it user mus authorize usage of the key in such case. In iPhone I would say it is protected and encrypted using the user password/pin/fingerprint so once you unlock the phone it can be used.

For authentication, (it does not matter if it is 802.1x EAP-TLS or another TLS or another method using certificates for authentication - everything works similary) you use this certificate signed with CA and usually something signed (encrypted) by your private key related to the certificate. It is usually some kind of challenge sent by the server and it is used to proof you own the private key related to the certificate you sent to server to be used for authentication and you claim it is yours.

Server then checks your certificate (if it is valid - date/time, if it is not revoked, if it is supposed to be used to do the action you are actually trying to do and if it is signed with trustworthy certification authority) then it uses the public part of the key stored in the certificate to decrypt the challenge to make sure you are owner of the certificate (the correct private key was used to sign the data) If the decryption is successful and the challenge matches the challenge sent to you for signing it actually means you are the owner of the certificate and you own the private key related to that certificate.

So what the server needs to know to authenticate you? Just the root CA or immediate CA authority certificate used to sign your certificate, your certificate including your public part of the key and the data encrypted (signed) with your private key related to the certificate. That's enough to authenticate and authorize you. It never needs to know your private key so there is no reason to store it in AD or in CA or wherever else than in your device.

Few words about the AD and MS PKI (CA service) - its same as stated above :):

AD never stores your certificate including private key. Why? Because it simply does not know it. It never did. If you ask for certificate in MS PKI (others work in the same or very similar way - EJBCA, OpenCA...) it usually works in the way you generate the private key on your computer, then you create certificate signing request. This can be done at any place, in case of MS it is on the CA server self service usually. CSR contains i.e.: distinguished name (name or email), your address, what purposes you request the certificate for - ie. authentication, email signing, whatever). Then you get the CSR, and you add some info to it, i.e. public part of the key, fingerprints, whatever. Finally, you sign the CSR (you hash the CSR and you encrypt the hash using your private key) then you send it to the self CA service portal. CA then generates a cert, signs it and delivers it back to you in pre-defined way. I.e. by placing it on the web or by email or, it probably could be integrated with MDM also.

In this case I am not 100% sure the described process works like this in detail but it will be very very close to it.


why CA use private key to sign a digital certificate? What is the logic behind sign a digital certificate with CA private key? In general(PKI), encryption happens with public key and decryption happens with private key. But, how Certificate Authority sign a digital certificate with private key? How this can be validated using public key in browser? What is the logic behind CA certificate validation?

What is the role of SHA (hash algorithm) role here? How SHA and CA private key work together?

Signing is one of two basic operations you can perform in public key cryptography:

encryption: encrypt with recipient's public key, decrypt with matching private key
signature: sign with sender's private key, verify with matching public key

The goal of digital signatures using private keys is to ensure that the message is as intended by the signer and not modified. Anyone can verify the integrity of the message (in this case: a certificate).

The hash algorithm is applied to the message (the certificate contents), the output padded to the length appropriate to the key size, then signed. This ensures two things:

we have an amount of data to sign that can be handled by the algorithm (eg: RSA, ECDSA)
that data is a representation of the contents themselves

It is important for the certificate signature algorithm to be a safe one (with no known practical weaknesses). This is why md5 and sha-1 are no longer recommended.

You can find more details about message signature using RSA in this crypto.se answer.


What are industry-standard recommended practices to protect user information in an Android app? I am developing an Android app that will potentially handle sensitive user data, and some of it may be even considered medical data (for example user height, weight, alergies, etc).

What would be the recommended security practices to protect the user's data both from the client-side perspective as well as the server-side?

I'm not talking about practices needed to get government certifications, but just strong, tested and recommended practices for good user info protection.

For example, on the client side, encrypting the database (with SQLCipher maybe?) at all times, and just decrypt the info when needed. If any of this information is to leave the device, then SSL would be a must. Never store a user's password. Authentication session handling, etc. Caching issues, should I cache frequently-accessed or decrypt it from db everytime it's needed?

On the server side, hashing and salting the passwords instead of storing plain-text passwords is also industry-standard.

Bonus points for references or explanations on how to correctly implement said practices.

Clarification: I'm not stating that the aforementioned example practices are indeed good practices, it's just to illustrate the kind of general practices I'm talking about.

Before I answer this I have to say something.

Security is one facet of development you can't just "wing", especially if you're dealing with sensitive user medical data.  While the attributes you have listed probably don't fall under HIPPA, if you make certain guarantees to users and the data gets compromised you may be in potential legal trouble.  If your security fails, it's not something you can just patch and make it all better; your users will lose confidence, and your reputation will suffer.

If this is a serious application that you're planning to make money on, then invest in it properly and hire someone who knows security to consult or help in the design/test process.  If it's just a fun side project and you feel like you "should have some security", I recommend you re-evaluate what you're planning.

To actually answer your question I would start by pointing you to OWASPs Mobile Security Project for Android.  This should give you enough information to read to explain the most common pitfalls.  For more formal resources O'reilly almost always has a book on whatever subject you're on.  Take a look at [Application Security for the Android Platform].2

Good luck.


Can a system administrator check if their website is being scraped by a headless browser? A recent article on scraping tiktok and Facebook states:

  On the one hand running selenium headlessly is perfect to keep your machine “cool”, however it may help get you flagged as a scraper. System administrators can spot a headless request with ease.

The author uses a random User-Agent for each request, so I'm not sure where the logs would indicate that a headless version of a browser making the request. Are there any specific signatures to detect a headless browser?

Good faith effort on the question:

With foresight, it looks like one could check make a check for things like webdriver version (which can be spoofed too). However, by stating sys admins, the quote seems to imply that the logs themselves are sufficient to detect a headless browser.

TL;DR "System administrators can spot a headless request with ease": NO. They can surely spot some headless requests with ease. But in general, that's not true.

Quite obviously, it all depends on how the requests are done (how much effort to disguise them) and how the logs are checked and what countermeasures adopted (how much effort goes into penetrating the disguise).

The fact is that an automated (headless or not) browser and a human can, and often do, perform requests in different ways, with different patterns. When they do, this difference can be spotted more or less easily.

The difference is often "intentional", i.e., it derives from a design choice - typically not executing some scripts or not downloading (some) images to reduce traffic, seeing and following transparent links or hidden parts of the DOM. Navigation patterns are clearly influenced by a human's response times. Also, patience and scope of the navigation might be inhuman by need - if you need to scrape a whole website, you won't use a "human like" navigation even if you could. And if you see someone browsing sequentially the whole site, you might not care for it even if you know it's a human.

A browser could also be analyzed actively, e.g. by intercepting mouse events and relaying them via AJAX; even if a headless browser correctly interpreted the Javascript code and was able to perform, in theory, those requests, it would never by itself understand that a human would perforce generate those events, or know how to credibly do the same.

But should a browser (headless or not) be controlled by a mouse and keyboard-like interface by an AI designed to interpret a screen rendering through OCR and scripting, and scrape a site like a human would, it would be almost impossible - and almost certainly intolerably rife with false positives - to tell it apart from a real human being.


How secure a secured PDF really is? I've googled the internet for answers regarding secured pdf/cracking them and found huge amount of stuff. But most of it is quite old. So could someone confirm the following is still valid in modern days.

pdf can have two password: the master one which prevents people from doing certain operation like printing,editing. This one is 'easily' hackable because it is based on the document reader software (hence if I wrote my own reader, I could bypass all the security checks in the document).

The second password is the user password (or open password) which is used to encrypt the document itself and enables you to open and read it. Without it you have no access at all. It's fairly hard to crack (need big amount of cpu).

I am correct?

LINKS:
Following are some of the links that I found intersting

The following White paper “How Secure Is PDF ?” by Bryan Guignard
http://www.cs.cmu.edu/~dst/Adobe/Gallery/PDFsecurity.pdf sums it up the best. However it’s states pdf v1.3 which dates back to 2000.

The issue were still alive in 2008 with Adobe Acrobat 9

LockLizard also has a link to this paper in its general issues section http://www.locklizard.com/pdf_security_news/  and they seem to keep the page up to date.

Finally this paper http://www.besthackingtricks.com/how-to-open-password-protected-pdf-documents-pdf-password-remover/ says roughly the same thing but only dates back to august 2015.

What you have said about the "permissions" password is correct. Certain readers (mainly those custom made) can simply choose to ignore it, and not enforce permissions.

As for the "master" password... Adobe Acrobat XI supports both the use of a password or certificate to encrypt the PDF document itself. Use of a plain password is defaulted at a 128-bit AES encryption level. This algorithm is strong, but obviously requires a key that is strong as well. 128-bit AES is supported from Acrobat 7 and later. If you were to look at Acrobat X or later, the algorithm support is 256-bit AES.

The certificate option allows for "all document contents", "contents besides metadata", or "only file attachments". Here the algorithms are 6.0 at 128-RC4, 7.0 128-AES, 9.0 256-AES.

You should also note there is LifeCycle permissions management in XI, but I haven't had time to look into that.


Chrome extensions: tool to notify users of ownership change (to avoid malicious code injection)? A problem with Chrome extensions was raised in an earlier question: extension owners can sell their extension to another owner, who can then insert malicious code.
From a user's perspective, they may trust the initial owner and install an extension, only to find malicious code silently installed months later when the extension is automatically updated.
I would like to be notified whenever an extension owner changes for an extension I have installed, so I can re-appraise it. It would be a bonus if those extensions were disabled until manually re-enabled.
Is there an existing tool which would do that for me?
If not, is it feasible to create such a gadget, say as a locally installed Chrome extension, or a shell script/cron job?

Ownership data could be scraped from the Chrome web store in order to track changes. With apologies for the shoddy code, here is such a scraper:
#!/usr/bin/env python3.8
import re, sys, urllib
from urllib.request import urlopen
from bs4 import BeautifulSoup

def processExtension(ext):
    print('EXT> ' + ext)
    crxbase = 'https://chrome.google.com/webstore/detail/'
    try:
        html = urlopen(crxbase + ext).read()
        soup = BeautifulSoup(html, 'html.parser');
        processSoup(soup)
    except urllib.error.HTTPError as err:
        print(err)
        pass

def processSoup(soup):
    for elem in soup('h1'):
        print ('TITLE> ' + elem.text)
    for elem in soup(text=re.compile(r'offered by')):
        if elem.parent.findChildren('a'):
            for ch in elem.parent.findChildren('a'):
                print ('OFFEREDBY> ' + ch.attrs['href'])
        else:
            print( 'OFFEREDBY> ' + re.sub( '^ *offered by *', '', str(elem) ) )
    for elem in soup('a',text=re.compile(r'developer')):
        print ('DEVELOPER_EMAIL> ' + re.sub('^mailto:','', str(elem.attrs['href'])))
    for elem in soup('span',text=re.compile(r'Website')):
        print ('WEBSITE> ' + elem.parent.attrs['href'])

for line in sys.stdin:
    processExtension(line.strip())
    print()

Sample output:
$ ls "~/Library/Application Support/Google/Chrome/Default/Extensions/" | ./extensionowners.py
EXT> mokjkiliipanjhlfbpagnmlpihmaohde
TITLE> Netflix Classic
OFFEREDBY> https://www.clickerfornetflix.com
DEVELOPER_EMAIL> help@dbklabs.com
WEBSITE> https://www.clickerfornetflix.com

EXT> nhbmpbdladcchdhkemlojfjdknjadhmh
TITLE> Crosh Window
OFFEREDBY> Chromium OS Developers
DEVELOPER_EMAIL> chromium-os-dev@chromium.org
WEBSITE> https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crosh/

EXT> nmmhkkegccagdldgiimedpiccmgmieda
HTTP Error 404: Not Found

EXT> occjjkgifpmdgodlplnacmkejpdionan
TITLE> AutoScroll
OFFEREDBY> http://kaescripts.blogspot.com
DEVELOPER_EMAIL> pcxunlimited@gmail.com
WEBSITE> https://github.com/Pauan/AutoScroll

EXT> ofhbbkphhbklhfoeikjpcbhemlocgigb
TITLE> Web Server for Chrome
OFFEREDBY> http://chromebeat.com
DEVELOPER_EMAIL> graehlarts@gmail.com
WEBSITE> https://github.com/kzahel/web-server-chrome


What's the purpose of signatures in Google Maps APIs? There's something I don't understand about signatures in Google Maps APIs.
The documentation says "We strongly recommend that you use both an API key and digital signature, regardless of your usage". In this case we are talking about the Maps Static API, where requests are made by the frontend with a URL that generates an image to embed on your website. API keys should be restricted by referrer, so nobody else will be able to steal your key and use it in another project. So what's the purpose of also adding a signature to the request?
As far as I know, signatures are used to make sure the request isn't modified by an attacker. But I don't think any parameters in Google Maps APIs can be abused in this case. What's even more confusing is the fact that if you check out other Google Maps APIs like the Distance Matrix API or the Roads API, they only recommend you restrict your API key (by referrer) and don't mention anything about adding a signature.
So is a signature really needed or not? And why?

Referrer restrictions are typically enough to prevent someone from reusing your API key in JavaScript on their own website, because the browser enforces the referrer information. But outside of a browser, referrer information can be easily faked (see: referer spoofing). So those restrictions are not enough to prevent someone from using your API key to send requests from a server, or from an offline tool. I believe preventing that is the purpose of these digital signatures.


Threat of a Windows XP machine connected to a local network via WIFI (today in 2018) After seeing this question I am wondering what could actually happen if a Windows XP machine was connected to a local network via WIFI. Imagine the machine will be used to browse the internet, read and write documents, so think of the usual basic tasks. I know WinXP is not supported anymore, and if I'm not mistaken I think some software (like Chrome) can't even be updated on such OS because the latest versions are not supported, so I know the threat comes from outdated software, but what I don't know is how exactly this threat can harm the local network.

I suppose it could be considered to be the same as having an attacker inside the local network, so the WinXP machine if infected could intercept, read, or modify all the traffic on the network (if not encrypted with TLS). Then portscanning, trying to find vulnerabilities in other machines connected to the same network. Am I right? Anything else?

I also wonder if this threat can be mitigated, or if the only way to deal with this is really to make sure that such an outdated machine is never connected to the network.

TL;DR - keep it off the web!

The longer version is that because is no longer supported, it is highly vulnerable and easy to exploit with almost no effort. (To see how little effort, search XP on https://www.exploit-db.com/). Vulnerabilities are being found more or less ad infinitum because of the volume of XP's still used - but there are no new patches being written for those vulnerabilities. With newer OS's, patches are at least identifying weaknesses and actively trying to mitigate them.

If someone is on the same network as you, it is child's play with nmap and metasploit to take over an XP machine. Even with most of your ports closed, XP has lots of attack vectors. To an experienced hacker, it takes a few minutes. I have fully compromised an XP with domain admin privileges in less than 5 minutes, and I'm not a "master" white hat by any means.

If you are behind a NAT firewall or some other means of protection (other than XP's joke of a firewall) it would be "safer," but still highly dangerous and susceptible to incoming traffic, downloading something via Trojan, and other risk factors that newer OS's automatically mitigate with little or no input from the user. This is doubly true if you use something like bit-torrent or other risky applications.

Finally, once your computer is compromised, it's a safe assumption that anything on that specific subnet is also fully compromised, and anything on adjacent networks is at extremely high risk and is either already compromised or will be soon, depending on what kind of malware you downloaded. Once a computer is infected, it serves as a beach head, jump box, landing point, or whatever else you want to call it to attack other computers - but there is NO firewall or protection between them. Domains, by and large, trust other computers on that domain. If this is networked to Active Directory for instance, those credentials will likely work on any other computer in the domain - and if someone compromises your AD server, you are in a very, very, very bad position.


Encrypting configuration on shared IIS7 hosting that uses load balancing When hosting a site on a cluster (or cloud configuration) we need to specify a Machine Key in the web.config file. This is needed to keep the machines in sync (often the first encounter with this is when you have to log in repeatedly after every one or two page loads).

Some say it's no use at all to encrypt the web.config on shared hosting. Others have some good points (watch out for editors that save .bak files for example).

Apart from database credentials, the config may contain some other credentials that may be of more direct use to an attacker, like root-admin credentials for forms-authentication (used for making and restoring database backups for example, where the user must be able to log in without relying on the database).

Is it possible to encrypt these sections with the provided means, since the "machine key" is defined in the same config file? If that key be used we have a nice chicken-egg paradigm!

It's shared hosting, so running aspnet_regiis is out of the question. I've also seen a lot of "Object already exists" and "key container could not be opened" problems on shared hosting when attempting to programmatically achieve encryption on projects that did not even utilize load balancing.

My question is, is it technically possible to encrypt the sections on shared- load-balancing (machine key in config) hosting with the standard instrumentation or should I spare any efforts.

Encryption is possible however at some point you must have a private key or a password that you need to use to decrypt the encrypted data. So the question is where do you put it?

In IIS you could store a certificate private key in a certificate store but in a shared hosting environment you probably don’t have that type of access. Also if you are trying to protect the data from the hosting provider they can easily get access to the key. If you are trying to protect a database connection password, being a hosting provider they probably host you database too so that won’t help.
I would however always salt and hash any passwords that would be entered in a login prompt stored in the web.config. Remember you don’t actually need to decrypt them, only salt+hash in the same sequence and compare.

You may still choose to encrypt the data as it may not be apparent what it is to the casual observer, however it would be trivial to break if they is what they intended.

Hope that helps.


Additional security benefits from Multi-Factor Authentication? Does multi-factor authentication provide any additional security benefits on top of doing a better job at correctly identifying and authenticating users compared to single factor authentication? In other words, if a system could perfectly identify users based on say biometric cues, is there still a need for additional factors to authenticate a user? As a real world analogue, if I want to limit use of my car to only say my spouse and I'm confident I can recognize them with 100% accuracy, would there be any additional security benefits to having a password or a token type of device between us?

"Biometrics" and "100% accuracy" are distracting the other people answering from the core question: "Are there any other benefits to MFA?" and that the answer is in fact Yes, there are other security benefits to MFA.

You're 100% certain you can identify everyone connecting to your site. You correctly reject an attacker attempting to brute force their way in. Many types of MFA, such as an SMS contact, allow you an out-of-band way to communicate with the authentic user to let them know their account is under attack. There are many reasons you might want to do this, even if both you and the user know their account is safe: To allow them to contact authorities and attempt to identify the attacker, for example.
Your system is 100% accurate today but may be compromised in the future. Reasons might include:

You make use of a crypto system that is strong enough to discourage all attackers now, but in a decade, technological advances have made it cheap enough to break the crypto that it's now worth attacking. MFA means the crypto system is no longer the only point of failure.
Perhaps when you say 100% accurate, you mean "This system is so hard to fool, that nobody would ever bother going to the expense of fooling it." (By creating a clone of your wife, for example.) This is an important distinction. If the value of information in your system increases dramatically at some point in the future, your security may now be inadequate, because the economics of breaking in have changed. MFA increases the expense further, improving your security from an economic standpoint.
Your IT staff introduces a serious bug in a future version of the product; your perfect system no longer works when that happens, but MFA could continue to work.

Your system is 100% accurate in the sense that only the authentic user can access the account. However, the authentic user can be forced, under duress, to access their own account. MFA may provide a way out of this situation for the user. For example, if it requires a physical device which is time-locked or location-locked, and can't be accessed even under duress.
This one is probably the most generally applicable: Access is about both authentication and authorization, and an authentic user who is authorized to use the system today may get fired, and no longer be authorized to use the system tomorrow. MFA can provide a double-check that their account is deactivated correctly. For example, if they must turn in their keys, including their code-generating device used for MFA, deactivating their account becomes a secondary concern.

The value provided by these benefits varies based on the value of the information you're trying to protect, what type of MFA you're using, what type of primary authentication you're using, and so on, but the bottom line is that someone may find these compelling reasons to use MFA even in a "perfect" system.