Can encryption really be "overcome" (by government) and how? I just came across this article. I am confused as to how, save MITM attacks or similar nefarious tactics, anyone can "overcome" PKI, which is founded on the substrate of asymmetric encryption, meaning that no decryption can be done using public keys? I am interested how the "masterminds" of this idea envisioned it be done, perhaps getting a hold of everyone's private key.

My understanding of PKI is fairly basic. Am I missing something?

That article strikes me as inspecific.

Modernly recognized quality encryption algorithms (e.g. AES which has been scrutinized for almost 20 years now) cannot really be 'backdoored'.

It could be 'cracked', but that would require a famous research breakthrough.

As is typical with mainstream articles, they don't really give us much to go on (unless I missed something) because it doesn't define the context.

In the case of Full Disk Encryption on smartphones and laptops, etc. The designers could decide to use a weaker Derivation function making it more susceptible to Brute Force. Or other built-in vulnerabilities. If that is indeed what the article is referencing, then we could discuss further.

However, the context could be completely different, such as HTTPS/TLS which refers to encryption of data in transit. For this, a compromised CA could be used to achieve MiTM. The website owners could work around this with Public Key Pinning, but I digress.

Without knowing the context, it is difficult to answer in detail. However I would summarize by saying that encryption algorithms cannot be backdoored, but a weak implementation could certainly be used.

As for public site visiting, like HTTPS, there is perhaps more room to fudge around by a) eavesdropping to begin with and b) compromising a CA without telling anybody. Still I think they would get caught if they used this technique frequently?

  there is no mathematically possible way to offer an encryption backdoor to law enforcement without weakening that encryption for everybody else

Even not knowing the context, I would probably concur with that statement.

Beyond that I'd say we need to look for a more specific article? Or perhaps Mr. Sessions just doesn't know tech well enough to clarify the How as you are asking.


Recommendation for identity system I want to develop a system, something like a comment system for a website, that ensures I know who is posting comments. The content that is exchanged is not valuable and does not need to be encrypted, I just want to have a some reasonable assurance that the person posting the comment is in fact who they say they are. If a post is spam for example, I want to be able to hold the person accountable. At the same time I need the system to be low overhead for users. For example giving them a list of 100 one time phrases that would have to be pasted into an email or onto a website would be acceptable.

I am using node.js and was considering using a diffie-hellman key-exchange.

I know this is fuzzy and I'm not looking for answers per se, but rather a way to think about it, an example or starting point or ... ?

Edit #1 Thanks for the intelligent questions and thoughts.

Use case: Someone physically comes to me and with a thumb drive and I give them a set of one time ciphers. [206,99087,3,etc]. And yes, they have to agree to give me some information and be physically identified. Each time they comment or post (and perhaps post through email) I want one of those ciphers to be sent to me, and they are not reusable. When my application gets an email or a posted comment there is a high degree of certainty about the identity of the person. Little is at stake besides "reputation" so there is little incentive to break into the system, but it shouldn't be trivial.

Accountability means their reputation suffers or they are banned from using the application. Since this is based on their physical person rather than their disposable email person this is sufficient.

Captcha are one of the best way to stop spam bot so you will need them somewhere, but they are a pain for the user. That's why I like when I can authenticate in some way to a system which means that I don't have to answer a captcha everytime.

Session cookie are the way to go to identify a client. He logs in 1 time (or proves that he is not a bot 1 time by answering) a captcha then you give him a session id inside a cookie. Actually there are usually 2 cookies, a session cookie and an authentication cookie. The session cookie is created as soon as the user connect to your site, the authentication is created when he logs in.

For blocking user, you could either block them by IP address, username or by terminating the session (invalidating his session cookie, so he has to reanswer a captcha). But if you chose to do it by username you have to protect the username by a password or anyone could impersonate any username.

Also, if you don't want your user cookie or login information to be stolen (by someone listening on your web traffic), you will need to encrypt all the communication between the client and the server using HTTPS. Otherwise, your cookies and login information are not safe. If an attacker gain access to a cookie he can impersonates that person.

I see 2 alternatives

Alternative 1 : Username + Password

Ask for a unique username, a password and an answer to a captcha when creating the account. After that, the client can simply log in with a username + password. If one account is a spam bot you can either block the username and/or the IP address.

Alternative 2 : Username only

If you don't mind to have duplicate username you can use this way. Simply, ask for a username and the answer to a captcha then gives the user a session cookie to authenticate him afterward. Of course, blocking by username is no use here and you should instead do it by IP address or terminating session.


Can I secure a server on which I'm deliberately allowing code execution? Context: AI competition. Users upload a dll with a class implementing a provided interface, then the competition runner instantiates that class and invokes various methods on the interface.

Obviously, this means that I'm intentionally allowing users to run whatever code they like as long as they wrap it up in an entry point that looks like my interface.

At the moment this is an internal company thing so we 100% trust all employees (no discussion of this, please), but it would be lovely to be able to make it more public.

Is it possible to make a system like this safe? How sandboxed can I make the dll's be? It's currently running in Azure. I assume that the box is backed up by some automated Azure stuff? (I didn't set up the Azure box)

A) Can I prevent them from interacting with anything else on the box?
B) Can I prevent them from accessing anything outside the Azure box?
C) Can I prevent them from accessing the Azure backups (i.e. If I say that I don't care if they trash the box, 'cos I could restore from backup, then is that safe?)

Since you are already running in a virtual environment, the simplest way would be to give each user a separate, small, environment to work with. If your operations team are any good, they will be using standard templates and/or scripting to create and tear down virtual environments in any case so this should be simple.

If you were using a Linux server, the easiest approach would be virtualisation via Docker.


Hashcat doesn’t write to output file I am using hashcat to crack a list of md5 hashes and have used the following command

hashcat -m 0 -a 0 -o out.txt --force hashdump.txt ../rockyou.txt

which gives the output

Session..........: hashcat
Status...........: Exhausted
Hash.Type........: MD5
Hash.Target......: hashdump.txt
Time.Started.....: Thu Sep 13 01:11:45 2018 (13 secs)
Time.Estimated...: Thu Sep 13 01:11:58 2018 (0 secs)
Guess.Base.......: File (../rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:  1459.2 kH/s (0.55ms)
Recovered........: 2/36 (5.56%) Digests, 0/1 (0.00%) Salts
Progress.........: 14344384/14344384 (100.00%)
Rejected.........: 0/14344384 (0.00%)
Restore.Point....: 14344384/14344384 (100.00%)
Candidates.#1....: $HEX[206b6d3831303838] ->
    $HEX[042a0337c2a156616d6f732103]
HWMon.Dev.#1.....: N/A

Started: Thu Sep 13 01:11:45 2018
Stopped: Thu Sep 13 01:11:58 2018

It is clear that 2 of the hashes have been found, however the file out.txt isn't created and I have know way of seeing the hash result.

Hashcat saves its progress in a .pot file. The --show command will let you see the cracked hashes that have been saved in the .pot file.

The FAQ will help with more details.


In SQL injection why don't we use OR 1 or OR 2>1 instead of OR 1=1? I read everywhere regarding SQL injection where it is said that if SQL query is:

SELECT * FROM table_name where username='xxxxx' AND password ='xxxx'

and if you want to enter always true condition then you will have to use 'OR 1=1-- then the query will be:

SELECT * FROM table_name where username=''OR 1=1--' AND password ='xxxx'

The logic behind the SQL query is simple since OR 1=1 is always true that is why it has been executed. However 2>1, 3>2 will always be considered true but why don't we use 'OR 2>1,'OR 1 expression in SQL injection?

You can use any expression that evaluates to true, it doesn't have to be 1=1, I don't think SQL contains a literal value for true according to this.

1=1 is the easiest for me to write and I got used to it.


Insecure versions of crypt hashes I read at crackstation not to use these variants of bcrypt* ($1$, $2$, $2a$, $2x$, $3$),but  I've used bcrypt ($2a$)  in various sensitive implementations recently.
Can any security expert clarify why recommending ($2y$, $5$, $6$) instead of ($1$, $2$, $2a$, $2x$, $3$), what is the original version proposed by Niels Provos, and in what they differ
bcrypt is a key derivation function for passwords designed by Niels Provos and David Mazières, based on the Blowfish cipher, and presented at USENIX in 1999. Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.

2 - the original BCrypt, which has been deprecated because of a security issue a long time before BCrypt became popular.
2a - the official BCrypt algorithm and a insecure implementation in crypt_blowfish
2x - suggested for hashes created by the insecure algorithm for compatibility
2y - suggested new marker for the fixed crypt_blowfish

So 2a hashes created by the original algorithm or the java port are fine, and identical to 2y-hashes created by crypt_blowfish. But 2a hashes created by crypt_blowfish are insecure.

5 is sha256crypt
6 is sha512crypt

The shaXXXcrypt algorithm are inspired by bcrypt but use sha2 instead of blowfish as hash functions in order to satisfy compliance requirements in the USA.


Tracing the reflected XSS attempts So, here is a piece of code I came across.

<?php

    $name = $_GET['name'];

    if (!empty($name)) {
            $name = str_replace("<", "&lt;", $name);    //line 1
            $name = str_replace(">", "&gt;", $name);    //line 2
            $name = urldecode($name);                   //line 3

            echo $name;

    }

    ?>

This code I found in one of the ethical hacking practicing frameworks named bWAPP at security level 1. The potential solution to bypass this technique is to URL encode the XSS string twice.

Let's assume my XSS string is

<script>alert('XSS');</script>       //checkpoint alpha

Then, encoding it once should give me

%3Cscript%3Ealert%28%27XSS%27%29%3C%2fscript%3E  //checkpoint beta

PROBLEM 1:
If I trace it down, on line 1 and 2 nothing happens. But on line 3 it gets decoded. And so, the resultant string I get back becomes checkpoint alpha. So, when I echo it, I should get an alert poped up.

CONTRADICTION 1:
Nothing like this happens and I just get the checkpoint alpha displayed in clear text.

PROBLEM 2:
When, I double encode it,(which is the potential solution to this problem), I get,

%253Cscript%253Ealert%2528%2527XSS%2527%2529%253C%252fscript%253E

Now, this statement again passes through line 1 and 2, and on stumbling upon line 3, it gets decoded to checkpoint beta and gets echoed.

CONTRADICTION 2:
When it gets echoed, I should get checkpoint beta in clear text but Suddenly the browser pops up the alert box with XSS working perfectly.

I am new in this field and currently trying to clear my basic concepts related to web development. Please pardon my incorrect statement formation.
Thank you.

When PHP retrieves the GET parameter with $name = $_GET['name'], it performs an implicit URL decoding. PHP doesn't require you to decode an URL parameter yourself.

These both result in the exact same value for $name:

http://yourapp/?name=<script>alert(1);</script>
http://yourapp/?name=%3Cscript%3Ealert%281%29%3C%2fscript%3E

So even if < looks like %3c in your URL, it will be stored as a literal < in $name. In consequence, the str_replace() part correctly recognizes < and > and filters these characters out, thereby preventing XSS.

The vulnerable part is the explicit urldecode() at the end.

If you provide the URL http://yourapp/?name=%253c, then variable $name will literally contain%3c (that's three characters) and the str_replace() functions will ignore it because neither of %, 3, c looks like an angle bracket. Then, in the end, urldecode() unnecessarily performs another decoding and turns the sequence %3c into a literal < after it has already passed the replace filter.

If it's still a bit unclear to you, replace $name = $_GET['name'] with this:

$name = urldecode('%253Cscript%253Ealert%25281%2529%253C%252fscript%253E')

You will see that this has the same effect as providing the string as the URL parameter and it shows that two urldecodes are redundant.


What type of security should I set up for a domestic webserver? I have set up a custom webserver hosted on a Raspberry Pi on my home local network.
The web app requests a single web page from the server via HTTP, and then sends user commands and receive information via websockets.

For now, I have only used the app within my (cable) local network and there is no security implemented at all, but I want to open the port to the Raspberry in my router to be able to connect from the outside world.

My requirements are that:

Commands should not be sent by someone without credentials
System information should not be read by someone without credentials

What should I set up to achieve such requirements? Is SSL required? If yes, could I use a self-signed certificate?

Yes, SSL will be necessary (well... technically, you can reimplement all your encryption need in the application layer, but it'll be very, very hard, it'll be much easier and more secure to leave writing the the encryption layer to the experts).

Yes you can use self signed certificate for this purpose since you control both the server and client.

However, server side SSL isn't sufficient for authentication. You'll either need to add authentication (e.g. some sort of Bearer token or HTTP Basic Auth), or use SSL Client certificate (mutual authentication).

Alternatively, you can use a Intranet VPN (not to be confused with Anonymizing VPN) to solve the encryption and authentication problem. Instead of trying to solve the prosblem at the endpoint level, instead you setup your own private VPN Intranet to connect to your LAN remotely.


Can I somehow require a specific certificate for a domain? My use-case is the following:

I have dyndns set up to access my home server from the internet. If I use a DV certificate or a self-signed certificate I'm not actually authenticating the machine but only the domain.

If my account runs out somebody can easily acquire the domain and use e.g. letsencrypt to get a valid certificate. At this point my applications might try to connect to the machine and transmit sensitive data which I would like to avoid.

I assume that doing this in a generic way is impossible but I would be happy about partial solutions that e.g. work only in a Firefox.

The only idea I have so far is to set up a script that will periodically check the certificates and alarm me in some way if they change. That, of course, leaves a window for attacks.

Could you not buy a domain name, CNAME that to point to your DynDNS. Therefore you use the domain name you just bought, then buy/letsencrypt a SSL certificate for the new domain and use that. (IF you already have a domain name even better just setup a CNAME with that one, personally I would avoid any applications connecting to the DynDNS name as this give you greater flexability in the future should you choose a different dynamic DNS provider, or even get a static IP)

A DV certificate is absolutely fine for this scenario. The other certificates, such as EV, authenticate the company and provide no real advantage in your situation. If you are altra-paranoid about spoofing your domain name then you can always check the public key of the certificate is as expected each time to attempt to connect.

There is also the CAA (Certificate Authority Authorisation) you could apply (Being very new is not widely used, and not in effect technically yet) but worth a read: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization


Is threat intelligence an illegal practise? When thinking about cyber security I like to be up to date with all the latest threats out there. So of course you would like to get the information first hand to see where the threats are coming from (Cybercrime Forums) Anyway is it illegal to engage with these users on forums to fine out more information of the threat?

Even if off-topic: It really depends on what country are you in. Even if it illegal or not you should protect your personal data and the metadata that can be leaked over such forums in order to not be related by several services with illegal action types.

Please:
Tor + Use only fake info + Use public IP's (bars/cafes) + adapt to the situation.


Attack vector for exploiting WhatsApp's retransmission "vulnerability"? A few days ago, an old "vulnerability" of WhatsApp re-appeared in the media.
The Guardian published this article calling the vulnerability a "backdoor". The article cites these findings of Tobias Boelter, a security researcher at UC Berkley.

The "vulnerability" is that WhatsApp automatically retransmits messages that have not been received by a client after that receiver changes encryption keys. The receiver is not notified of the key change and the sender is only notified if they switch on an option (which is disabled by default) buried deep in the account settings.

After a rather general response from Facebook/WhatsApp ("We do not have a backdoor"), Open Whisper Systems, the maker of the Signal protocol that powers WhatsApps E2E encryption, now responded directly to the article in this blog post. Both are essentially claiming that this is not a vulnerability but a UX issue (whether or not to prominently notify the user of the change of encryption keys).
Tobias Boelter again responded in this blog article, saying that it is a vulnerability that would allow an attacker to "wiretap targeted conversations".

My question is:
What does a real-life attack look like that would exploit this vulnerability?

I firmly believe that very few people actually dig three levels deep into the WhatsApp settings to enable the security notifications, so let's assume that most people could be attacked without seeing the warning about a change in cryptographic keys. How, then, could a motivated attacker take over Alice's end of a WhatsApp conversation without Bob noticing?

It seems this would require the attacker to temporarily block Alice's access to WhatsApp (putting her offline, leaving Bob's messages undelivered) and then take over her WhatsApp account (how?). As long as the attacker could thereafter impersonate Alice reasonably well, Bob - not being shown a warning about the key change - would then believe he's still communicating with Alice.

What does a real-life attack look like that would exploit this vulnerability?

Here is a possible scenario:

Alice lives in an oppressive government. She communicates with journalist Jonas over WhatsApp with the intent to leak information about a political scandal.
Afraid of being revealed, Alice one day panics and destroys her phone without telling Jonas.
A day later, Jonas sends her a message "Is it okay if I name Bob as the source?". Alice of course doesn't receive that message because her phone is gone.
The government instructs the telecommunication service provider to identify a new phone as having Alice number. They go back online, verify to WhatsApp that they own Alice phone number and announce a new keypair so that they can read any messages that are sent to "Alice" in the future.
Jonas' WhatsApp recognizes that Alice seems to be back online with a new key. Because the last message hasn't been transmitted yet, Jonas' WhatsApp will automatically resend that message and encrypt it with the new key. (If Jonas has turned on his security notifications, he will be told that Alice  has a new key, but he won't be asked if it's safe to re-encrypt the message for the new key.)
Government can now read Jonas' latest message and learns that Bob leaked the information.

Tobias Boelter explains this in a similar way in his blog post:

  Imagine you dump your phone into the ocean and only a month later you get a new phone. Then during this one month time period, some friends might've sent you messages. In WhatsApp, your friends phones are being instructed to automatically re-encrypt and retransmit. But they don't know if they are sending the messages indeed to you or the government. Then, and only if your friends specifically asked WhatsApp to do so, they will see a warning that there could've been something shady going on. Signal on the other hand will tell your friends something like "there might've been something shady going on. Do you want to resend your message?".

Currently, there is no setting in WhatsApp that needs a sender to confirm if they want to re-encrypt a message for a changed key if the message has not been delivered yet. However if the message has been delivered, the sender can't be tricked into re-encrypting it.

As I understand it, Facebook is concerned that adding a confirmation dialog for retransmission with changed keys impacts the user experience in a way that drives WhatsApp users away to less secure messengers, having an overall negative impact on people's security. On the other hand, Boelter argues that the added security of such a feature outweighs the minor impact on usability.


Why is it a security problem not to update one's browser? Is it in general a security problem not to update your browser. Firefox constantly prompts me to update my browser, but how dangerous is it to not update?

As part of this question, I would like to know what that problem exactly is. What are the risks of not updating your browser? What exactly could happen?

Because there are security vulnerabilities found in software all the time.  These vulnerabilities are sometimes publicly disclosed, sometimes not.  Either way, as developers find or find out about them they patch them.  Running old versions of browsers leaves you vulnerable to malicious websites trying to infect your computer.
Below are links to web pages listing vulnerabilities that have been fixed in relatively recent versions of the 3 most popular browsers.
Microsoft Internet Explorer
Mozilla Firefox
Google Chrome
All browsers are going to have bugs, and all of them will have vulnerabilities.  But staying on top of known vulnerabilities can help prevent attackers from gaining access to your system.
Edit
Thanks to kirb for these extra links to up-to-date blogs of browser security updates
IEBlog
Google Chrome Releases


Certification or Course equivalent to OSWE? Is there any certification which focuses specifically on web application penetration, CWE issues and code analysis like Offensive Security Web Expert (OSWE) does? OSWE is not available online and it is not feasible for me to attend until they organise it in my home country :D. But if there is a way which I am not aware of, please let me know.

Why I am taking reference is because, as everybody says on different forums, offensive security courses are practical and gives you real insight in things rather than just theories. Correct me if I have wrong impression of anything :)

I'm not sure that such question is a good fit for this website but anyway...

I have heard good things about eLearnSecurity certifications which seems to be the de-facto alternative to the eternally """soon-to-be-published-but-not-ready-yet""" OSWE.

However, they do not seem to have yet a lot of recognition in job offers and last time I checked the certification exam was one week long, making it hardly compatible with a full-time job (I hope and guess that sometime they will change this. Yes you can do your exam during your vacation, but in case of a technical issue during the exam you are screwed.).


Is Apache vulnerable to CVE-2015-1781? Is Apache vulnerable to CVE-2015-1781 (buffer overflow in the gethostbyname_r() family of functions)?

How can I quickly check if a system of mine is secure?

You must check the version of your glibc first: using this command can help:

ldd --version

The end of the answer has a good things you can skip and go there

According to this reference this vulnerability works on glibc version before 2.21-3.
if your glibc is older than this version it is vulnerable.

The problem has been fixed upstream but a new version has yet to be
released.

Also there is another vulnerability that Last revised is: 04/13/2015 and also is related to glibc version 2.20 and before it.

Also read this one: Red Hat alert RHSA-2015:0863-01 (glibc)

Arjun Shankar of Red Hat discovered that the nss_dns code does not
adjust the buffer length when the buffer start pointer is aligned.  As a
result, a buffer overflow can occur in the implementation of functions
such as gethostbyname_r, and crafted DNS responses might cause
application crashes or result in arbitrary code execution.
This can only happen if these functions are called with a misaligned
buffer.  I looked at quite a bit of source code, and tested applications
with a patched glibc that logs misaligned buffers.  I did not observe
any such misaligned buffers.[Reference]

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

This is another vulnerability related to glibc and gethostbyname() this artice said:
"to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,

nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,

pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,

vsftpd, xinetd."

So I think like this vulnerability your mentioned vulnerability does not affect on apache

and maybe this vulnerability has an effect on Apache or maybe not, but untill clarifying this issue. the fast countermeasure is upgrading glibc to last version.


Is there a point in randomizing my WPA2-Personal SSID (meaning, set a random string in place of the SSID)? I was looking for ways to make Wi-Fi that uses WPA2-Personal/WPA-PSK secure, and I stumbled in this answer (the second one, from Terrence Koeman):

WPA2-PSK (aka WPA2 Personal) basically does the same thing as WPA2-Enterprise from the clients perspective: The client associates to the access point, authenticates to the access point using the pre-shared key and access point creates a 256bit PMK (pairwise master key) from the SSID and the pre-shared key (PSK). This PMK is then used to encrypt data traffic using CCMP/AES or TKIP.
[...]
There are ways to make WPA2-PSK somewhat more secure, in that it would take months to crack it instead of minutes (pre-computed rainbow tables) or hours (dictionary attack): Set your SSID to a random string of the maximum length (64 I think), since it's used as the seed for the PMK, and use a random pre-shared key (PSK) of the maximum length. If you then change the key monthly you can be reasonably sure that nobody has a current PMK or had/has access to your network.

Now, given that the PMK is created using the SSID as a seed and the pre-shared key (which is the, correct me if I am wrong, the Wi-Fi password), if I use a strong, random password, is using a random string as SSID really necessary to make it secure? Isn't a strong password enough?

Using a strong password is enough. If you use a pseudorandom password of 19 characters, that will give you a key with about ~113 bits of entropy. NIST requires symmetric keys of at least 112 bits so you should be fine with a 19 character pseudorandom alphanumeric password, even if the password is being cracked on a supercomputer.
In fact, normally, your WiFi AP broadcasts its SSID, so it is already known to the attacker. Therefore it adds no entropy to your PMK (it is included only as a salt) and there is no point in keeping a long random SSID.


What encryption prevents the tampering of Windows Identity Foundation (WIF) FedAuth cookies? It occurred to me that the WIF FedAuth cookies contain identity information, that if tampered with, could permit someone to assume the identity of another user.  Fortunately, WIF does cryptographically Authenticate the message, but I don't understand how this is done.

What happens first, Authentication or Encryption (AtE or EtA?)
How is the authentication portion implemented
Are any other standards implementing a similar encryption?

Based on the first answer of this link :

  This cookie is encrypted and signed with the DPAPI key that is associated with the IIS application pool.

For your information :

  DPAPI provides an essential data protection capability that ensures
  the confidentiality of protected data while allowing recovery of the
  underlying data in the event of lost or changed passwords. The
  password-based protection provided by DPAPI is excellent for a number
  of reasons.

  It uses proven cryptographic routines, such as the strong Triple-DES algorithm in CBC mode, the strong SHA-1 algorithm, and the PBKDF2 password-based key derivation routine.
  It uses proven cryptographic constructs to protect data. All critical data is cryptographically integrity protected, and secret data is wrapped by using standard methods.
  It uses large secret sizes to greatly reduce the possibility of brute-force attacks to compromise the secrets.
  It uses PBKDF2 with 4000 iterations to increase the work factor of an adversary trying to compromise the password.
  It sanity  checks MasterKey expiration dates.
  It protects all required network communication with Domain Controllers by using mutually authenticated and privacy protected RPC channels.
  It minimizes the risk of exposing any secrets, by never writing them to disk and minimizing their exposure in swappable RAM.
  It requires Administrator privileges to make any modifications to the DPAPI parameters in the registry.
  It uses Windows File Protection to help protect all critical DLLs from online changes even by processes with Administrator privileges.

Now, for the order between Authentication and Encryption, regarding this documentation, WIF seems to first Encrypt, then Authenticate.


Phishing emails sent to my contacts, from another contact Some people on my email contact list have been receiving phishing emails that appear to come from someone else on my contact list.  The people receiving the emails and the person purportedly sending the emails are not themselves contacts.
If people on my contact list were receiving phishing emails from my account I would just conclude that my email was hacked, but what should I make of the fact that the emails are coming from this other email?  Specifically, is it a "known" procedure for attackers to send phishing emails to a contact list, pretending to be someone else on the same contact list?  I guess the attacker's assumption is that people on the same contact list will know each other?

This was a common facet of Emotet, which would not only send spam to people found in your address book, it would also quote older emails of yours to act as Bayesian poisoning. While Emotet has been seized and shut down by authorities, its techniques are not unique.
A piece of malware infecting a computer can harvest contacts. It might be your computer, it might be somebody else in your address book. If you're seeing crosses between contacts of yours that do not know each other, it's probably you (update your a/v, disconnect from the network, reboot, then do a full system scan. If you still find nothing, consider professional assistance since some malware will corrupt your system in order to evade detection once it's installed).
Another possibility is that the attacker is harvesting addresses from public archives of mailing lists.


Can client-side hashing improve after-the-fact security in response to password leaks? Several questions on this site address client-side password hashing, and none of them admit to any security benefit beyond protecting other sites the user might use the same password for.

However, there seems to be one circumstance that has not been addressed, where I feel client-side hashing may improve security after-the-fact against some leaks - notably Heartbleed. The best response to such bugs is indeed changing passwords, yet users are hesitant to do that and websites almost never wish to require it.

Imagine hashing went like this.

The client has a plain-text password.
This is hashed to H0 and then to H1.
This is sent to the server, which hashes this to H2, which is stored in the database.

Then let's say Heartbleed happens, or some hacker injects code into the hasher to email H1 to himself, or any other security bug happens that completely compromises the server (but not the client) for some period of time. The exploit gets discovered and fixed, yet all H1 hashes are deemed compromised.

Let's say, like experience shows, resetting everybody's password is not an acceptable response for business reasons.

With this method, one can work around this.

Patch the client to now send (and the server to now require) the hash H0.
H0 becomes the new password.
H0 is unknown to the hackers, yet still verifiable by the server.
If needed, an alternate hash, H1', can be produced from H0 to replace H1.

Obviously this still reveals enough to allow local brute-force attacks by the attacker, so it is not a full cure. However, it seems much preferable to leaking the plain-text password, especially if the user is not willing to update it or will at best replace it with "${old_password}2".

I know little about security, so I've likely missed some important caveat, though. Thoughts?

There are no theoretical benefits from hashing client-side and server-side to hashing twice server-side ; unless the connection between the client and server cannot be trusted.

However in practice, I have seen multiple instances where plain-text passwords ended-up in logs (mostly in error logs). In this particular scenario it has a clear advantage.

I believe you hashing from H0 to H1 is feasible with a salt that is unique per password.

Once H1 is compromised, because the server knows this particular Salt, the client could authenticate by sending H0, and then the server can check that H0 + Salt => H1. Then the server could change the Salt to Salt' and register the H0 + Salt' => H1' as the new password.

I think this is possible, but I'd advise against it :
Complexity is the enemy of security.


Explicit SSL / TLS version selection I have posted this question in SO but didn't receive any help. Therefore, I am trying my luck here at SE.

In a nutshell, framework such a .NET allow us to switch the SSL/TLS version before we connect to any specific https service. This agreement ensure that both client and server connect and consume http over agreed version of SSL/TLS.
As far as I aware, the agreement of SSL/TLS version negotiation happens upon SSL/TLS handshake.

Question: Can someone explain why framework allow such use case when  negotiation was suppose to be performed at the stage of TLS handshake?

I think you understand the API wrong. The function you mention is not used to select a specific SSL/TLS version. The argument to a function is a SecurityProtocolType Enum which has the following documentation:

  Specifies the security protocols that are supported by the Schannel security package. This enumeration has a FlagsAttribute attribute that allows a bitwise combination of its member values.

Note that it talks about combining multiple values here and not a single protocol version.

In other words: this is not used to select a specific protocol version but to set a list of allowed protocol versions. Typically you want to have TLS 1.2 and higher, maybe TLS 1.1 and TLS 1.0 for compatibility reasons but you don't want to allow SSLv3 or lower. By using this API you can tune which protocols are allowed within the following TLS handshakes.


How does SSL implement server authentication? I already know the basic concept like public key and private key, the message encrypted by public key can be decrypted by private key, and vice versa, but I just can't understand how client know the requested server is the right one and I want to understand the detail of the process.

The client compares the server hostname you type into the URL against the subject name in the certificate. If they match, then it's the right server. If they don't match, then it's the wrong server. That simple.

See: How does SSL/TLS work?


How to properly secure an ActiveMQ instance, and what are all of the different files for? I'm trying to configure user based authentication for ActiveMQ, and I'm pretty confused about the many different files involved in this process.  I've read ActiveMQ's security page, but I still have several questions.

Just to be clear, my goals is to make it so only a specified user can read or write to ActiveMQ or access the web console.  These can be local ActiveMQ users, LDAP is not needed.

I have successfully realized that in order to configure access to the web console I need to configure the users in conf/jetty-realm.properties, but beyond that I'm stuck.

Ok, so the files that seem to be related to authentication in the conf folder are...

credentials.properties
credentials-enc.properties
groups.properties
login.config
users.properties

On top of that, the security pages recommends using the  "simpleAuthenticationPlugin"

<simpleAuthenticationPlugin>
    <users>
        <authenticationUser username="system" password="manager"
            groups="users,admins"/>
        <authenticationUser username="user" password="password"
            groups="users"/>
        <authenticationUser username="guest" password="password" groups="guests"/>
    </users>
</simpleAuthenticationPlugin>

In the broker

So my understanding is..

users.properties seems like where the users should go, but I don't see the point the simpleAuthenticationPlugin if this file exists.
group.properties seems like a place to configure the groups, ok.
login.config seems like it just points to users.properties and groups.properties, ok.
credentials.properties seems redundant.  It looks like users are being configured in here. Not sure why this exists if users.properties exists.
credentials-enc.properites seems like a place for encrypted passwords, but again why does this exist if users.properties exists?

My questions are...

What is the proper way to configure a local user on ActiveMQ and
make it so they are the only ones who can read or write to the
queues?
What is the purpose of each of the following files?

credentials.properties
credentials-enc.properties
groups.properties
login.config
users.properties

Does the simpleAuthenticationPlugin make these files obsolete?

At the time I am answering this, this question is 2 years old, so my answer might include things that have changed from the time this was posted.  Ill answer the second question first:

credentials.properties     -> clear text passwords
credentials-enc.properties -> Encrypted passwords, if configured
groups.properties          -> a list of groups, and what users are members
login.config               -> a file to configure more advanced auth like ldap integration
users.properties           -> a list of user names.

So I found this question while trying to figure out some of these things myself, so I am no expert.  But I will share what I have learned.

Everything above other than login.config is now irrelevant.  or it seems that way to me.  If you are trying to configure LDAP integration, you have to deal with login.config, but otherwise... I think that one is also irrelevant.  The things that do something when I mess with them:

jetty-realm.properties
This is the important one right 'out of the box'.  It is formatted like:

userName: securePassword, nameOfGroupUserIsMemberOf

so if you want the 'foouser' user to use the password 'barpasswd', and be a member of the 'buzgroup' group, this file needs a line:

foouser: barpaaswd, buzgroup

OK, so how does ActiveMQ know to call this file?  By default, it is configured in the file:
jetty.xml
This is a very important file.  Many of the instructions I found for LDAP integration suggest changing this file... but I cant get it to work.  If i figure it out, I will amend this post.
The other important file is:
activemq.xml
At the time of this post, the official docs suggest altering this file for several reasons.  One of them is for LDAP integration... but those instructions do not work as far as I can tell.  Above, you discovered altering this file  to hard-code user accounts.  I think they include this for backward compatibility, but I am not certain.

Now i will answer the first question.  Once you have users configured in jetty-realm.properties, you can configure activemq.xml with permissions.

an example:  https://svn.apache.org/repos/asf/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/security/jaas-broker.xml
you can see it in the authorizationMap section...

More notes for anyone interested:

When I followed the instructions to encrypt passwords, the service stopped loading.  The reason seems to be the formatting of the file 'credentials-enc.properties'.  When I reformatted to be like 'jetty-realm.properties', the service would load, but ignore the encrypted passwords.  Fun. I tried putting the encrypt passwords in 'jetty-realm.properties', no joy.

I can get activemq to encrypt and decrypt text, but be aware that the documentation says that only alpha-numeric are supported.  No spaces, nothing else.

Also, I will provide links to the pages I found, but they all conflict, and I got little to work other than the default setup.

What I know about LDAP integration:
if you use JAAS, do not try to use a newer version.  Do not try to use jetty-plus as they suggest in some of these links.

https://www.middlewareinventory.com/blog/active-mq-installation-and-security-setup-and-hardening-step-by-step/
https://activemq.apache.org/encrypted-passwords.html
http://activemq.apache.org/cached-ldap-authorization-module.html
http://activemq.apache.org/security.html
https://stackoverflow.com/questions/52686757/activemq-web-console-using-ldap-active-directory-authentication/55244956#55244956
https://bacedifo.blogspot.com/2013/06/securing-activemq-580-web-console-using.html
https://steamingpileofsoftware.blogspot.com/2013/10/secure-your-jetty-activemq-web-console.html


GPG: Can't encrypt DSA 3072 keys I would like to ask this question as I'm not the first person which has
this behavior.

I'm trying to encrypt a simple message using GnuPG using a public key I've
received from a friend, he's using DSA 3072 but for some reason,
whenever I try to encrypt using his public key, I get

gpg: <mailaddr>: skipped: unusable public key
gpg: s: encryption failed: unusable public key

Here's the output of gpg --list-key when I lookup my friend's mail

pub   3072D/fingerprint some-date-here
uid                  Name1 <mail1>
uid                  Name2 <mail2>

Here's my GPG --version output

gpg --version
gpg (GnuPG) 1.4.19
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I'm asking here as I recently got mail from people claiming the same (I'm also using DSA 3072 on my key).
Can anyone shed some light on this topic ?

DSA is a signature algorithm; its keys are not usable for asymmetric encryption. In the OpenPGP format, algorithms for encryption are RSA and El-Gamal.

Normally, when you create your keypair, you are actually producing several key pairs: a "master" key, and some "sub-keys" for signing and for encrypting. The master key signs the sub-keys. When you say that you use "DSA 3072", you really mean that your master key uses DSA 3072. Similarly for your friend.


How to access an HTTPS service running deprecated technology? (TLS 1.0) (phone works but not PC) So this is the issue: I have a modem/router provided by my telco.
The router exposes the usual 192.168.1.254 address for managment, but with my pc there's no way to open it, I tried with firefox, explorer and chrome.
Firefox says "SSL_ERROR_RX_RECORD_TOO_LONG", explorer says to enable tls 1.0 (done) and chrome says "ERR_SSL_PROTOCOL_ERROR".

With chrome on android I can connect and via a tool I see the site uses TLS 1.0, WITH AES_128_CBC AND HMAC-SHA1. Plus there's a self signed certificate.

I understand these encryption methods are deprecated, but is there a browser for pc that can connect anyway?

I'm sorry that I do not know of a modern tool designed to work with deprecated HTTPS servers.

Normally Firefox would give you an "Add Exception" button. (hidden behind "Advanced" on the error page) Google Chrome has a "Proceed Anyway" button. However it sounds like you are not getting those options.

Many routers offer an HTTP only option to bypass encryption entirely. (no HTTPS)

Clear Cache on your browser.
Try specifically navigating to http://192.168.1.254 (no https)
If that does not work, (redirects you to HTTPS Error page again) access via your phone (since that is working for you), and look for settings:

Many routers offer a way to turn off HTTPS, or at least to not redirect HTTP users to HTTPS.
If you can't disable HTTPS redirect, there may be settings to customize either which Cipher Suites or which HTTPS settings are available. If you find them, try to turn on new technologies and/or disable old technologies, and see if your Firefox browser will connect. You can even post a new question once you find out which settings are available.

(Often you have the ability to replace the self-signed certificate with a verified certificate, but that probably won't help if the HTTPS configuration is deprecated.)

If all else fails, install an old version of the Firefox browser and see if that works.

  Warning: Using old versions of Firefox poses a
  significant security risk.

Directory of older versions and languages

  Important: By default, Firefox is set to automatically update itself.
  If you install an older version of Firefox, you'll need to change your
  update settings to prevent the latest Firefox version from being
  reinstalled. See Advanced panel - Accessibility, browsing, network,
  updates, and other advanced settings in Firefox for details.


Hashcat mask attack getting error "seperator unmatched" I'm trying to crack the password Ul1234 using hashcat. I created a user with that password in kali and copied the hash in the shadow folder:

nils:$6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNsI6u3TKEkKVXb3gNQKhcK/C6y1DW6q4ODNIJrjf1ondgZ7RHqD7kprI1:18296:0:99999:7:::

So the hash should be :

$6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNsI6u3TKEkKVXb3gNQKhcK/C6y1DW6q4ODNIJrjf1ondgZ7RHqD7kprI1

i copied the hash into file nils2.txt and typed the following command:

kali@kali:~/Documents$ hashcat -m 1800 -a 3 ?u?l?d?d?d?d -o ans.txt --force nils2.txt
hashcat (v5.1.0) starting...

OpenCL Platform #1: The pocl project
====================================
* Device #1: pthread-Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz, 1024/2955 MB allocatable, 2MCU

Hash '?u?l?d?d?d?d': Separator unmatched
No hashes loaded.

Started: Wed Feb  5 09:08:13 2020
Stopped: Wed Feb  5 09:08:14 2020

I don't understand why I'm getting an error

$6$ is definitely part of the hash. It indicates the hash type (sha512crypt). The $ as field separator is a long-standing hash idiom and is part of many modern password hashes.

Instead, the issue here is that hashcat's parameters are positional in a way that may not be intuitive. Masks always appear after the target hash or hashfile:

$ hashcat -O  -m 1800 -a 3 -o ans.txt nils2.txt ?u?l1234
hashcat (v5.1.0-1651-g050f6b0e) starting...

[snip]

Session..........: hashcat
Status...........: Cracked
Hash.Name........: sha512crypt $6$, SHA512 (Unix)
Hash.Target......: $6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNs...7kprI1
Time.Started.....: Wed Feb  5 06:11:40 2020 (1 sec)
Time.Estimated...: Wed Feb  5 06:11:41 2020 (0 secs)
Guess.Mask.......: ?u?l1234 [6]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:     1265 H/s (0.98ms) @ Accel:64 Loops:256 Thr:1 Vec:2
Recovered........: 1/1 (100.00%) Digests
Progress.........: 650/676 (96.15%)
Rejected.........: 0/650 (0.00%)
Restore.Point....: 0/26 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:24-25 Iteration:4864-5000
Candidates.#1....: Ua1234 -> Uq1234

Started: Wed Feb  5 06:11:36 2020
Stopped: Wed Feb  5 06:11:41 2020

$ cat ans.txt
$6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNsI6u3TKEkKVXb3gNQKhcK/C6y1DW6q4ODNIJrjf1ondgZ7RHqD7kprI1:Ul1234


Download mirror security As with a large amount of open-source softwares, (Debian, Eclipse, PHP) you can apply to become a mirror of their site/downloads. I fully understand that this helps them with bandwidth and distribution.

However, what stops people uploading malicious copies of the software to their mirror?

I know some sites offer MD5/SHA1 hashes of the download, to ensure your download is valid, however does anyone without a tinfoil hat actually check these?

TL;DR

If I download an ISO from http://www.debian.org/distrib/ how do I know it's legit?

Package managers such as aptitude which is used on Debian implement GPG keys to authenticate the package. The Debian install will come with the public key of the package signer, which is then checked before installing downloaded packages.

Sometimes you'll find you end up with an error if this process fails:

W: GPG error: http://www.debian-multimedia.org etch Release: The following signatures couldn't be verified because teh public key is not available: NO_PUBKEY 07DC563D1F41B907
W: You may want to run apt-get update to correct these problems

You can see more details about the solution, called SecureApt, here: https://wiki.debian.org/SecureApt

To address your revision regarding the downloading of installer CD images:

Yes, multiple mirrors exist and one of the primary delivery methods (HTTP) is vulnerable to a MITM attack which could modify the image in such a way as to make your installer contain a rootkit. However, unlike updating packages, installing the base system is a much less frequent event.

Manual PGP protections are also in place for the CD images. Firstly, all disc images on the mirrors should provide MD5 and multiple SHA hashes for every image. These hash files are themselves signed by Debian to ensure they also cannot be forged on a mirror site.

Before downloading the ISO, verify the integrity of the SHA256 or SHA512 (most secure) using for example gpg.

gpg --verify SHA512SUMS.sign SHA512SUMS

This will give you an error if you don't currently have the public key the file was signed with. In that case check the signature given and compare it against the trusted keys on Debian's website: http://www.debian.org/CD/verify

This is the most important part of verification, because integrity of the hash file revolves around the integrity of the key you trust.

Once you've verified an appropriate key, install it in your keychain like so:

gpg --recv-key --keyserver subkeys.pgp.net LAST8CHARSOFFINGERPRINT. This
fetches a key matching the signing key's fingerprint from a server.

Finally, gpg --verify SHA512SUMS.sign SHA512SUMS should now tell you whether the hash file is authentic. If it is, you can safely compare the result of your sha512 chosen.iso with what's in the sums file.

Naturally this all assumes you run these commands from a trusted computer, where sha512 and gpg are unaltered by an attacker.

YPMV (your paranoia may vary).


Better protocol for Web app I have many Web applications developed as Node.js based servers horizontally scaled with a Load Balancer in front of them. At the beginning all my Web applications exposed HTTP endpoints and the Load Balancer provided SSL termination for them. Now i'm thinking about the value of providing HTTPS endpoints instead of HTTP ones at the application server level. I think it is a good practice and my question is: Is this desired, recommended or required for you folks from a security standpoint?

25% of attacks were perpetrated by internal attackers is what the Verizon Data Breach Investigations Report reports.

I cannot think of anytime that HTTPS should NOT be used.


Join a computer to the domain or not? If we have a computer on the network that is only used by one person that logs on using a local account, no noe will log on using a domain account, what are the pros and cons of joining/not joining this computer to the domain from a security stand point?

Joining a Windows computer to an ActiveDirectory domain is a trade off.

Pros:

Client management via Group Policy Objects (GPOs)
Single sign-on access to resources and services
Credential recovery (admin can reset your password)

Cons:

Lack of autonomy
Need to be attached to the network or on VPN for first authentication (can be cached afterwards)
Transitive trust attacks (compromise endpoint, pivot into services or systems, cryptolock shared file systems)

Client management and single sign-on are very significant advantages in a workplace or institutional environment.  Managing clients individually rapidly becomes unmanageable even with small numbers of deployed workstations.  Inconsistency breeds problems and undocumented vulnerabilities.  Client management allows you to enforce aspects of your written security policy such as password complexity, local firewall rules, and software restrictions.

Single sign-on is significantly advantageous as well.  It means being able to centrally manage the authentication of services allowing staff to either log in once (ideally) and have their credentials provided transparently to all integrated corporate resources.  Without this you get a proliferation of credentials managed (likely poorly) by the individual services and users reusing the same passwords leading to compromise.

Credential recovery is a big one too.  Without it a staff person could be left without access to their workstation and may lose work.

I think the security consequences of unmanaged workstations outweigh their benefits.  Exceptions should be made for staff members demonstrating a dedication to defined security policies and a willingness to hand their machine over to be audited.  One size fits all will annoy people and encourage non-compliance.


Is it secured to store the encrypted key in the database (encrypted by other cipher)? I want to improve the encryption flow used by my application.
Today I use the AES cipher while its key and its IvBuffer are hardcoded in the code.
I know it is not secured and I want to improve this.
I want to create a new AES cipher while its key will be stored in the database.
The key will be encrypted by the old AES cipher.

Application will use the new AES cipher:

Decrypt the key for the new cipher using the old cipher.
Encrypt / decrypt information using the new cipher using the decrypted key.

The flow will allow easier key rotation in the future (I can elaborate it but it is not related to my question).

How the encryption process is secured?

What to do with IvBuffer for the new AES cipher?
To store it in the database or to put hardcoded in the code?

Added

I understand from the answer below that the additional hardcoded key does not improve my security. I need store the encryption key in the database (option 7 listed here Where to store a key for encryption?). Unfortunately I can not use external devices for the key storage and therefore I need to use database.

Question if the security of the option when key is stored in the plain text in the database is better that the option when additional hard coded key is used for the same key stored in the database?

If I understood you correctly, you want to continue using the old key, which remains hard-coded, but only use it to encrypt AES keys, which are then used to encrypt and decrypt your data.

This does not improve your security. The vulnerability in your old design is that the key and IV are hard-coded. If you encrypt the new key with the old key, that adds an extra layer of complexity (because you need to handle multiple keys) but it doesn't actually fix the issue you had (hard-coding a key). If you want to do key rotation, as you say, you should replace the old key with the new one after re-encrypting the data you used to encrypt with the old cipher.

As far as the IV goes: from a cryptographic standpoint, as long as IVs are unique per encrypted text, these are public. For example, in CBC mode, the IV is just the first input that you XOR onto the plain text; for all subsequent blocks, the cipher text of the previous block is used for that. What matters is freshness.

Alternatives to hard-coding

Storing your key in a database is better because you at least have the ability to change the key later. If you properly protect the database (i.e., password protection and encryption), that could be a reasonably secure solution. However, it is likely easier to use an existing library that stores your key in a file, protected with a passphrase. That would mean that to access the data, your logic would consist of:

get the passphrase
extract the key from the file using the passphrase
discard the passphrase from memory
decrypt the data using the key, encrypt and write any new data
discard the key from memory

You can likely get all the passphrase stuff done using a library. I recommend you open a second question if you've got more questions about that topic.


Google shows indexes of non-existing hacked-like URLs of my site and cached to other pages Today I tried site:mysite.com at google and noticed that I have pages indexed with urls that shouldn't be there for example instead of

mysite.com/item/123/apple_wifi_review

I have:

mysite.com/item/123/children.Also

This page goes to the item number 123 on my site anyway but I wonder where has google got this url.

To make it worse I can see this url on google:

mysite.com/redirectUrl.php?elementId=494

Which if I click goes to "not found page" on my site but google cache show a page belonging to another site.

There is one other possibility (other than what's mentioned by @bacon-brad):

Hackers don't always deface the site they hack.

It is possible that your site was once hacked and cached from that time. Redirection is not unusual when hacked (even today) and serves multiple purposes ranging from drive-by downloads to malicious ads to click-fraud.
If you've recreated / done major changes to your site since the hack-time, it explains you seeing "page not found" on your site but a cached site points somewhere else.


Do mobile apps have their own certificate store? When a mobile app is sending HTTPS requests, it verifies the server certificate against some kind of certificate store. My question is, would that certificate store be provided by the phone's OS, or would it be packed with the app?

I know I can do certificate pinning, but first I want to know what's the default.

If there's any difference between Android and iOS, I'd want to know that.

The short answer is that it depends on the application's implementation. Certificate pinning is not a default, it is rather a custom implementation. Default is to rely on system trust store - on iOS as well as Android.

In general the security best practice is to use SSL pinning. Pinning could be implemented in two ways - Including the entire certificate store to the client package  or by including the signature for a certificate to the client package. You shall be able to verify this by reversing the client package.

Similar to the way most desktop applications work, mobile applications also by default rely on the trust store provided by the operating systems. On Android OS's before Android 7.0, the user could install a custom certificate to the system trust store from an SD Card. This resulted in trivial MITM attacks and the capability has since been removed from later versions. Applications no longer trusts user installed certificates on android devices.


ADFS 2012 R2 (3.0) JSON web token validation Our client would like for us to utilize ADFS 2012 R2 (aka 3.0) as the primary means for two security features in internal apps that we are building:

The web app (there are two .NET & Angular) and an iOS app will use the OAUTH flow within ADFS
Upon completion of the token flow, the JWT created by ADFS will be passed to a RESTful API that is being created with Spring
The Spring API will then need to validate the JWT before allowing the call to proceed

Using ADFS for the OAUTH flow is new to us and a few questions have popped up. We've scoured the Internets looking for answers. Many of them are singly focused on delivering a solution using MS only tech (ADAL, .NET/C# based APIs, OWIN, Katana). Thus, we hoped to crowd-source an answer via SE. Any and all help is much appreciated.

At this point, we have been able to:

Register an OAUTH client with the PowerShell command in ADFS
Register a "fake" Resource as a Relying Party in ADFS
Setup our clients to make a call to ADFS to authorize and then get the returned JWT

This link was very helpful in explaining the setup:

http://blogs.technet.com/b/askpfeplat/archive/2014/11/03/adfs-deep-dive-comparing-ws-fed-saml-and-oauth-protocols.aspx

Now, we need to put the code in place in the Spring API to verify the JWT.

In all examples of OAUTH flow, there is a shared secret between the issuing party and the client. This secret is used to verify that the JWT has not been spoofed.

In the setup we have done thus far in ADFS, there is no definition of a secret key or shared secret. We can grab the JWT from the authorization header and decode it. But we seem to have no means to verify the signature.

The question is how do we validate the JWT within the Spring API (passed from the client via the header) that comes back from ADFS without having the "secret" that was used to build the signature?

Our options if we do not get this to work are:

Use Oracle Identity Manager / Access Manager (already in-house)
Bring WSO2 Identity Manager into the picture

If I understand your question correctly, the signature is a RSASSA using SHA-256 hash based on the configured Token Signing Certificate.

I've got a Node.js validation example on GitHub and here's a blog post with a few more details.


How wireshark capture packets in LAN without arpspoof? I created a lab environment which has Windows 7 and Kali Linux in VMware.

In Kali Linux, I opened Wireshark and started to listen to traffic on eth0. After that, in my Windows 7 machine, I opened an HTTP site and entered some login information to that site.

Wireshark was able to capture that login information.

How does Wireshark capture those packets? Windows 7 sent its packets to the router but Wireshark was able to capture them.

I didn't use arpspoof for MITM attack so I didn't trick Windows 7 into thinking the Kali machine was the gateway nor gateway as kali machine is windows 7. So my guess was Wireshark shouldn't capture those packets but it did capture them anyway.

Anybody can tell me why?

This is actually not a security question at all. The question you want to be asking is how one node on a network can see the packets that are not destined for it. For this answer, you need to understand how Ethernet networking works.

Ethernet networks are broadcast networks, meaning that every node on the same segment can see every other node's traffic. No tricks required.

A switch, and a wifi access point acts like a switch, breaks up these broadcast zones (mostly) so that only the nodes that need to talk to each other see the traffic. That's why you need to arp-spoof: you need to trick the victim node to send you the traffic first and then you pass it on to the intended destination.

But without a switch, everyone can see everyone's traffic. So, your Kali's Wireshark could simply and easily see the traffic being sent by the other node. No tricks required.


Not destroying cookies at log out As a beginner pentester, I was pentesting one of our applications and found that the cookies are not getting destroyed when a user log outs. The cookies did come with an expiration time and date.

What I checked:

Without logging in, I tried to access a URL that lies behind the login, but I sent that HTTP request with the cookie that I had noted down before logging out. I was able to access the page as if I am a logged in user. Later, I tried the same URL with the same cookie, but after the expiry time of the cookie and as expected, the URL threw a 403 forbidden error. Is this a normal practice? Or should I ask the app owners to destroy the cookie as soon as the user logs out regardless of cookie's expiry date?

A session has presence both on the client and on the server:

On the client, the session identifier is stored in a cookie with a limited lifespan.
On the server, the session is stored somewhere and typically also has an expiration date.

Logout functionality needs to handle both: remove the cookie from the client and terminate the session on the server. The latter is most important, or else the session remains valid even though the client no longer has the cookie. This seems not to happen in your case. Ask the developers to terminate the session on the server when a user logs out.

  Without logging in, I tried to access a URL that lies behind the login, but I sent that HTTP request with the cookie that I had noted down before logging out.

So you logged out and could still access a page for which you should be authenticated. This means that on logout the session is not terminated, which it should.

  Later, I tried the same URL with the same cookie, but after the expiry time of the cookie and as expected, the URL threw a 403 forbidden error.

This means that the session has expired on the server. The sessions on the server have a limited lifetime, which is good. This could be the same duration as the cookie expiration time, but it doesn't have to be.

  Or should I ask the app owners to destroy the cookie as soon as the user logs out regardless of cookie's expiry date?

Yes, this is reasonable to ask.


What is the difference between privilege escalation and authorization bypass? As I understand when a user with low privilege does some actions only available for users with high privilege this is called privilege escalation.

And authorization bypass is when I do some actions which I don't have the permissions to do, if I'm not mistaken.

What is the difference?

These terms focus on different aspects of the attack: privilege escalation describes what was achieved, i.e. gaining higher privileges, no matter how. Authorization bypass describes how things were done, i.e. by bypassing the authorization, no matter what was gained this way.


How does SSH know which public key to use from authorized_keys? When an SSH client connects to an SSH server using public key authentication, the server encrypts a message using a public key from authorized_keys, and the client must prove it can decrypt the message.

How does the SSH server know which public key to use for a given client?

The client cannot be sending the public key to the server, as according to this answer the client doesn't need the public key to login:
https://security.stackexchange.com/a/42847/174597

Note I am not asking about how public key authentication works. I am asking which public key does a typical SSH server (e.g. OpenSSH) use to encrypt the challenge sent to the client, from a list of keys stored for example in authorized_keys?

RFC 4252 provides guidelines on how public key authentication should work, but it is not entirely specific on the exact order of the exchange. That said, it was stated in the comments that OP is not interested in RFCs but rather the implementation details for "SSH on Linux", which refers to OpenSSH in most cases.

Connecting to a remote host over SSH with the verbose -v flag, you will typically see the following for each key:

debug1: Offering RSA public key: .ssh/id_rsa.pub

Further, we can look at the source code. After a quick skim, the following is relevant:

if (PRIVSEP(user_key_allowed(ssh, pw, key, 1, &authopts)) &&
        PRIVSEP(sshkey_verify(key, sig, slen, sshbuf_ptr(b),
        sshbuf_len(b), NULL, ssh->compat)) == 0) {
        authenticated = 1;
}

The user_key_allowed function checks for the key in an authorized keys file, while the sshkey_verify appears to verify the signature of some buffer.

Combining this information, it appears that the client will use all of its keys until the server accepts one. This is also evident by the fact that having multiple keys present during a single connection attempt may appear on the server as multiple authentication attempts since all of the keys are tried.

Additionally, see @nbering's comments for the details on the challenges/signatures.

Edit: Here's an example where I have several keys, and only the third one tried is accepted by the server. Using -vvv:

debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:QfriqWH2S2uD6wHbxTFSudppOcJ51bB5ABr8ICrUhL8 .ssh/id_rsa2
debug3: send_pubkey_test
debug3: send packet: type 50 # SSH_MSG_USERAUTH_REQUEST
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51 # SSH_MSG_USERAUTH_FAILURE
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:3M8bnhs+jGJm8X2cgnWzzMrfoeT3WmDkSp8AEr751Sk user@laptop
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: RSA SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI user@laptop
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60 #  SSH_MSG_USERAUTH_PK_OK
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI
debug3: sign_and_send_pubkey: RSA SHA256:CQeP9lcYBVqV11Rn8Ca4Sv+W8l8uU63WQ4TpyG5ZMmI
debug3: send packet: type 50
debug3: receive packet: type 52 # SSH_MSG_USERAUTH_SUCCESS
debug1: Authentication succeeded (publickey).

This again closely follows RFC 4252, pages 8-9.


Diffie Hellman - how large should the random number be? When using the Diffie Hellman exchange with the second Oakley group 1024 bit Prime per RFC 2409 (*), how large should the random numbers generated by both sides be?

In RFC 2631 this is called the private key, and I'm quoting:

  X9.42 requires that the private key x be in the interval [2, (q -
  2)].  x should be randomly generated in this interval. y is then
  computed by calculating g^x mod p.  To comply with this memo, m MUST
  be >=160 bits in length, (consequently, q MUST be at least 160 bits
  long). When symmetric ciphers stronger than DES are to be used, a
  larger m may be advisable.

I'm going to be using AES-256 for the content encryption.

I don't know what q is for the second Oakley group.

Is 160 bits enough? Do I need to go as high as 1024 bits?

Needless to say I have a noise-generation capacity problem and I'm hurting already, so I need the least amount of noise that still keeps the system secure (at a roughly 112 bit equivalent bits of security which is approximately the level of security provided by the DH with a 1024 bit prime).

(*) I know this prime is not great, is being deprecated and all that. This is a legacy system for which I cannot enlarge the prime.

EDIT - clarification on my motivation: I'm using a good physical real random number generator (no "pseudo" magic). Yet to maintain statistical independence of the output there is a max sample rate. There is a scenario in the system which requires a fast setup of thousands of secure connections. I would rather not store the noise on disk in preparation for this scenario (lots of pitfalls down that path, let alone certification requirements) nor "expand" the noise using one of many techniques.

Short answer. Yes, I think it is fine to choose x as a random 160-bit number.  (I would not bet my life on it, but I'm pretty sure it is fine.)

Technical details. There are (at least) two ways to attack Diffie-Hellman.

One way is to use fancy algorithms for computing the discrete logarithm, e.g., based upon the number field sieve or the like.  The running time of these algorithms is dependent upon the prime modulus p, and you need p to be large (certainly at least 1024 bits) to resist these attacks.
Another way is to use more basic algorithms, such as the baby-step giant-step algorithm or Pollard's algorithm.  The running time of these algorithms is dependent upon the smaller of the size of q or the size of the exponent x.  You need q to be large (at least 160 bits) to resist these attacks.  You need the exponent to be chosen from a large space (i.e., at least 160 bits of entropy) to resist these attacks.

Since there are two different attacks, you'll need to choose your parameters to defeat both.  That's why you need your exponent to be at least 160 bits.

Now the most conservative thing to do is to choose x uniformly at random in the interval [0,q-1] (or [2,q-2] if you prefer, it doesn't really matter).  This will surely be secure, as long as p and q are big enough.  The quote you pulled out seems to be saying that X9.42 recommends you use this conservative approach.

However in many cases you can get away with an optimization, sometimes known as the short-exponent optimization.  The idea is you choose x uniformly at random from some smaller interval, say [0, 2160 - 1].  This is usually secure, if the protocol is designed right, though there have been some exceptions.  The benefit is that if q is large, choosing a shorter x like this can significantly improve performance.

For the group you mention, q = (p-1)/2. (*)  In other words, q is around 1023 bits long.  This means the most conservative thing to do is to choose your x to be from the full range [0,q-1], but I believe you can probably get away with using the short-exponent optimization.  I tried to read the IKE documents, and I didn't immediately find an explicit statement of whether the short-exponent optimization is always guaranteed to be safe for IKE, though I did find some passing remarks which seem to indicate that the developers did anticipate it might be OK to use.

Footnote (*): You can infer this as follows. RFC 2409 says that the "properties of these groups are described in [RFC2412]". Section E.2 of RFC 2412 lists the corresponding group, and lists the largest prime factor of the group order.  The largest prime factor can be verified to be (p-1)/2.  From this, it follows that q = (p-1)/2.

Edit 3/24: I just noticed, thanks to @CodeinChaos's answer, that you mentioned your reason for using a short exponent is not performance but rather the limited entropy in your PRNG.  I find this a bit odd.  What PRNG are you using?  Are you sure you have a crypto-strength PRNG?   Most cryptographic PRNGs can be used to pull an arbitrary-length pseudorandom string.  If yours doesn't, then you can always take the output of your PRNG and expand it to a 1024-bit pseudorandom string: e.g., generate a 128-bit AES key K, then use AES(K,0), AES(K,1), AES(K,2), AES(K,3), ..., AES(K,7) to generate a 1024-bit pseudorandom string.  Once you have a 1024-bit pseudorandom string (as long as it is crypto-quality and the original RNG has enough entropy in it), you can use that as a full-length 1024-bit exponent.

Do check that your RNG/PRNG is crypto-strength.  For example, /dev/urandom and CryptGenRandom are good, but rand(), random(), drand48() are all bad.  (/dev/random is strong but unnecessary; use /dev/urandom instead, and you will be able to draw a full-length exponent with no problems.)  Search on this site for more information about crypto-quality PRNGs.


Software vs Hardware Firewalls I read an article (can't find link) recently that advocated dumping software firewalls if you had a hardware firewall.

I was just curious as to the take on Firewalls in general for a small-medium office. Assume we had a router with a dedicated hardware firewall behind it that filtered and routed traffic before it hit the LAN.

Would it be worth the effort to maintain the firewall software that typically comes with A/V or Windows these days? I've seen many times where we are diagnosing PC issues and once the firewall is off, the problem goes away. Typically this leads to us turning the software firewall back on though after customizing the rules for the application which had issue.

Does anyone agree with the idea that a hardware firewall is enough of a defense or is it worth having the software firewall also?

Per fianchetto - When I say hardware vs software  I should clarify to gateway firewalls (At the perimiter or router level) and endpoint firewalls (software firewalls on the desktop or laptop).

First, all firewalls are software firewalls.  Some have 'fastpath' technologies which offload packets matching fingerprints which have already been evaluated in software to ASICs or realtime systems, but firewall decisions are made by software stack.  Most firewalls run on a variant of linux or BSD, with their own kernel modules implementing low-level firewall tasks and userland code handling packets which the kernel module deems must be inspected at a higher-level, but some, primarily Cisco, have their own operating system.  In either case, the firewall architecture is not 'hardware' or 'black magic'.

I think that you are making a false differentiation and what you should actually be comparing is "endpoint firewalls" versus "gateway firewalls".  Pedantry notwithstanding, it is important to note that this is the actual distinction rather than hardware versus software.

Second, it is a best practice (nist 800-41), and a compliance requirement in any sizable organization, to have segmentation not only at the perimeter, but internally as well.  In some cases (specifically, laptops, which move from security zone to security zone...and even to places where there is no security at all), it is extremely difficult to meet this requirement with gateway firewalls.  In such situations, endpoint firewalls are useful.

My personal experience and preference with regards to endpoint firewalls is not to use them to meet security requirements, except when absolutely necessary (like laptops).  I rather see them as an added bonus.  Being that it is extremely difficult for me to manage centrally, and for me to ensure that all system owners are compliant, I must have network-level control.  If a sysadmin wants to manage iptables in addition to that, I commend them, but I cannot rely on that.


What are the implementation details and rationale of ASP.NET MVC3's AntiForgeryToken? The AntiForgeryToken is used to prevent CSRF attacks, however the links on MSDN don't give me much insight to what exactly the AntiForgeryToken does, or how it works, or why things are done the way they are.

From what I gather, it creates a hash inside a web page and a cookie.  One or both of them use the hashed IPrincipal.Name, and use symmetric encryption.

Can anyone shed light as to:

How the AntiForgeryToken works internally
What should it be used to protect
What should it NOT be used to protect
What is the reasoning behind the implementation choices for #1 above?

All CSRF is prevented by the use of cryptographic nonce which cannot be obtained by the attacker due to Same-Origin Policy.  This is not a problem that Symmetric Cryptography can solve.

Check out the CSRF Prevention Cheat Sheet.


Can Your ISP use a Packet Sniffer? Can ISPs presumably use packet sniffing applications such as wireshark and monitor my unencrypted data? Are they "allowed" to do so?

Generally speaking, unless there's something specific that prevents them from doing so, then they can.

Legally speaking, a contract might make this disallowed,  but it's very unlikely that this would be in your contract.  Similarly, local privacy laws might protect you.  Either way, it's lawyer time - but how will you ever know?

Technically speaking, unless your data is properly encrypted, yes they can read and modify anything they want.  Use SSH or SSL to connect directly to the resource you want to access.  Or use TOR (or an SSL tunnel through a third party server - like an anonymizer service) if you are worried specifically about your ISP, but aren't concerned about "another" ISP.

Value-wise, a smaller organization probably isn't that interested in you personally, and probably won't target you.  The NSA should be assumed to be collecting your data.  Organizations like Google do automated data mining to give you directed ads - these organization s target you generically, not directly.

Do you have a raeson someone at your ISP might specifically target you, or why someone might get a job at your ISP or hack your ISP to target you?


Is there a risk of a bootstrap problem when using NTS? Reading up on the NTP protocol wikipedia page as well as blog posts about NTS, it appears like NTS uses TLS to start the encrypted connection. From what I understand, TLS might not work properly if there is a significant difference in time between the server and client. If so, doesn't using NTS mean that if the client system time is misconfigured, the NTS call might fail because the TLS connection can't be established?

The thing about TLS 1.3 is that both parties do not need to be within a single timeframe to be performing the handshake, or share time-related information at the start. TLS 1.1 & TLS 1.2 however, had a time element in its Client Hello message

TLS 1.1 & TLS 1.2 Client Hello Message,

Structure of this message:

      The client hello message includes a random structure, which is
      used later in the protocol.

      struct {
         uint32 gmt_unix_time;
         opaque random_bytes[28];
      } Random;

Under the gmt_unix_time variable as seen above, here are the documentation for TLS 1.1 Client Hello Message & TLS 1.2 Client Hello Message

  The current time and date in standard UNIX 32-bit
        format (seconds since the midnight starting Jan 1, 1970, GMT,
        ignoring leap seconds) according to the sender's internal clock.
        Clocks are not required to be set correctly by the basic TLS
        Protocol; higher-level or application protocols may define
        additional requirements.

With the above paragraph supports the fact that even with the time involved, it is merely used in a way to randomized the message.

TLS 1.3 Client Hello Message, here is the documentation for TLS 1.3 Client Hello Message

Structure of this message:

      uint16 ProtocolVersion;
      opaque Random[32];

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

      struct {
          ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
          Random random;
          opaque legacy_session_id<0..32>;
          CipherSuite cipher_suites<2..2^16-2>;
          opaque legacy_compression_methods<1..2^8-1>;
          Extension extensions<8..2^16-1>;
      } ClientHello;

The variable gmt_unix_time has been removed in TLS 1.3

Despite NTS using TLS 1.2 and TLS 1.3, initial time would not be an issue!


Browser gives access to root directory through "/" If I put a '/' on my browser I have full access of my root directory. I have tried the same thing on another computer and it didn't work. So, I'm trying not to be paranoid but this is too strange. I have tried to check open ports using:

lsof -i -P | grep -i "listen"

but each time I kill any of the ftp open ports processes it opens another. Is there any way I can fix this? I think I have a netcat running on my computer and just can't get rid of.

Also if I check the network using netstat it gives me some datagrams without any information, everything is with a "*" value.

Please help!

For many Linux browsers (I've tested Opera, Firefox, and Konqueror), this is normal: a bare / is an invalid URL (there's no protocol), and it gets interpreted as file:///: "display a directory listing of the root directory".  There's no security risk here: only you can display the contents of your computer's root directory using a file: URL, you cannot display the root directory of any other computer, and browser security policies keep Javascript from accessing it.

The file:/// URL (or its Windows equivalent, file://c|/) is often used in scareware scams: the scammer will display it in an iframe on their website and try to convince you that it represents some horrible security leak, which their software can patch.


SSL Mixed Scripting Vulnerabilities and XOR Attacks Given that RC4 is a stream cipher (I'm pretty sure the details of its inner workings don't matter for the sake of this argument) and the existence of Mixed Scripting / Mixed Display (web applications requesting and retrieving contents both over unencrypted and encrypted channels). Does the combination of a stream cipher encrypted SSL session and a mixed scripting / mixed display vulnerability not constitute grounds for an XOR attack?

I understand that if content is requested unencrypted we essentially have the plaintext, but what would one not be able to retrieve the SSL sessions symmetric encryption key using such an XOR attack? i.e. [encrypted request] XOR [unencrypted request] = some key bits?

What you call the "XOR attack" is based upon the secret stream being reused; i.e. there is some secret stream S, data D that gets encrypted by XORing it with S, and some other data D' that gets encrypted by XORing it with the same secret stream S. In that case, if the attacker knows D he learns D'.

However, when RC4 is used in SSL, the key is brand new for that connection, and the various data elements that get encrypted are XORed with different parts of the stream. An important security feature of stream ciphers is indeed that key-dependent stream bytes cannot be guessed from knowledge of other bytes of the same stream. A good stream cipher is akin to a cryptographically secure PRNG: without knowledge of the key, chunks from the same stream still appear unrelated to each other.

(Of course RC4 has its own shortcomings, e.g. known biases; but, at least, SSL employs it properly, i.e. with a new key for each connection.)


How can I re-use my password and still protect the password if it is exposed from one source? I know that all servers should at least store my credentials as hash(password + salt) + salt, with a secure and well known hash function and a salt unique for me, generated from a secure and well known source.

The problem is that servers should do that but may not, so as a user I can't trust them.

I am looking for what I can do to my password before sending it to the server, so that if the server is storing plaintext for example, it will not compromise the security my password on other servers.

I was thinking of sending hash(password + service) to the servers with the service being  "Facebook" or "Amazon" for example. This way if someone get hash(password + service) stored in plain text from that service, that's as if they found the hash of my password + the salt, unique for that service.

I already see a problem with that idea: someone could create a rainbow table for each service, making the use of the service as a salt useless.

I know the rule don't invent your own crypto/protocol, that's why I want to know if there exists a know protocol for a client securing himself?

You are trying to solve a problem that you shouldn't have in the first place: Password Reuse

The concept is simple. You think of a "good" password and use that for everything. Your bank account, online shopping, your e-Mail provider, etc.

The problem is, if it gets leaked by any one of them, then all of the other accounts are potentially in danger. This is a completely unnecessary risk!

What about my suggested scheme?

You yourself said don't re-invent the wheel. If you were to actually do that, you would either have to write an application that calculates the hashes for you, or calculate them yourself and store them.

There are already applications that solve the problem of credential storage, and they do a way better job at it: Offline Password Managers

Why are Offline Password Managers better?

Because they generate truly random and unique passwords. There is no need to bring cryptography into this. No need to tie my password for my e-Mail account to it somehow containing the string "gmail.com".

Because SN2\ZJ2Cw92DQx^{$OmqAC_P'xR|Md)[ is definitely a better password than the MD5 sum of hunter2+gmail.com (it's 01f9a94a0febf268495d08f5960e7f05, in case you were wondering).


AWS RDS MySQL database publically avalible We currently have two EC2 instances and a RDS instance. Both a EC2 instance and the RDS instance a hosted on AWS in the same region. However, the second EC2 instance is on a different region.

Currently we have limited access to the RDS instance to only allow connections from the first EC2 instance using Amazon's VPC and security groups.

We need to allow the second EC2 instance to access the RDS database but currently cross region support for security groups/VPCs are not support. So it looks as though we need to open the RDS instance up to the public internet (looks as though we can limit it to the second EC2's IP address though).

What are the security concerns about doing this? It is running MySQL 5.6.27. It has a strong password associated with it's access (but I don't know if this is sufficient). I can provide more configure details if needed.

Thanks

Database protocols are not designed to support hostile public exposure. Even source IP protections may be insufficient, due to IP spoofing, lack of transit encryption and other issues.

Perhaps reconsider the architecture by either using a read replica in the second region and sending customers who need to do writes to the EC2s in the master region, or just by shutting down the other region EC2 instance.

The other-region deployment of EC2 may not help for performance, because transactions still have to travel to the master region. And it may not help for availability, because if the master region is lost then presumably the lone EC2 instance won't be able to do very much.


In GSM is it correct to say A8 uses the random generated by the Auc and Ki to generate Kc? In GSM is it correct to say the AuC uses A8 algorithm with as input a nonce and Ki to generate Kc used for encryption communication between the subscriber and base station? If not how is Kc forwarded to the mobile subscriber in a secure way?

The referenced presentation describes how the protocol works.

The A3 algorithm is used for authentication and A8 for key derivation. They both take as input:

A random 128 bits number challenge
Ki a 128 bits private key (included in the SIM and known by the network)

A3 outputs a 32 bits response. And A8 a 64 bits Kc cipher key that will be used for A5 algorithm.

As both inputs can be known to the base station and the subscriber's device, there is no need to forward Kc to anyone. It's computed on the spot.


Are all anchor tag href attributes considered XSS vulnerabilities? I've got an app which allows users to customize the "thank you" message that is displayed to users when a form is submitted.

For the "thank you" message contents I've whitelisted allowable HTML tags and their corresponding attributes. One of the tags that I allow is an anchor tag and it's corresponding href attribute, so that users can add links to their "thank you" messages.

I recently received a report from a pen-tester who claims that my thank-you form is susceptible to cross site scripting because it is possible for a user to execute JavaScript from the href tag, as such:

Is this XSS?

Any other attributes are stripped from the anchor tag.

Questions:

Is this technically considered XSS?
If so, how can I mitigate this "attack"?

From reading this question it appears that I could require the href attribute to start with either an h or a /. Would that be sufficient?

Is this technically considered XSS

Absolutely.When the user click's the tag the javascript will get executed in the context of the domain.So it is a legitimate XSS.

  If so, how can I mitigate this "attack"?

OWASP XSS prevention cheatsheet is an excellent resource for such questions.

They state that

  Do not encode complete or relative URL's with URL encoding! If
  untrusted input is meant to be placed into href, src or other
  URL-based attributes, it should be validated to make sure it does not
  point to an unexpected protocol, especially javascript links. URL's
  should then be encoded based on the context of display like any other
  piece of data. For example, user driven URL's in HREF links should be
  attribute encoded.


Prevent Plain-Text Passwords Output by a Script From Being Accessible in the Future Let's say I have a Bash script that generates a password, creates a new user with that password, and then tells me what the password is:

# Generate a password and set it to $PASSWORD
PASSWORD=$(tr -dc '[:graph:]' < /dev/urandom | head -c $(shuf -i 24-32 -n 1))

# Create a new user and set its password to $PASSWORD
useradd --home-dir /home/tom --create-home tom
echo "tom:$PASSWORD" | chpasswd

# Output the $PASSWORD
echo "The password is: $PASSWORD"

I will execute this script, as root, only one time.

After the script shows me the password, I will manually note it into my secure password management system.

I do not want the plain-text password to ever be visible on the system again, even to the root user (to the greatest extent possible).

1. Will it be possible for someone to see the output (plain-text password) of this script in the future, and if so, how can I remove it from the system?

2. What can I do (if anything) to make sure the contents of $PASSWORD are never accessible after the script has finished?

The script you wrote does not put the password into any easily accessible long-term storage (like a file). Even if typical linux auditing would be enabled (which would write all unix program invocations to a log file, including arguments), the password is not visible, as it is only passed via streams. The only exception is the "echo" command, which happens to be a shell builtin on bash, so it is not a "unix program invocation".

If the script finished, the memory allocated to $PASSWORD is freed, and if another processs happens to allocate that memory, it will be cleared before. But the memory used for "$PASSWORD" (or the copies made inside chpasswd, the echo builtin, the graphics library to display the password) is not necessarily cleaned after termination of that script. If you happen to use a GUI with a console window, the password obviously is in memory as long as you can scroll back to it. Depending on security settings in the kernel, root processes might be able to search the whole physical memory or swap space for copies of the password, but any program allocating memory via the kernel is guaranteed to not find the password in there, because the memory will be cleared before it will be handed out for another process.

If your computer has plenty of memory, or the password ended up in swap space, it might be around for along time after you script finished. Having no swap (or disabling swap and clearing the whole swap partition/file) prevents the password ending up in the swap file. Allocating and overwriting lots of memory can clear the password from memory, but is a dangerous thing to do on linux because the OOM killer which will kick in just as you can be sure you have overwritten all memory that might contain the password might kill some unrelated process.

If you need security against memory scraping, the password generation would have to make sure that the password is never copied to uncontrolled memory, and the controlled memory is cleared before the program exits. There is no way to do that in shell. I think the is even no way to display a password (short of writing it to video memory yourself) which is 100% guarantueed of not copying the password to some random memory.


How to perform an idle scan against a target using Nmap with a list of zombies? I want to perform port scan against a target but the firewall at the target only allows traffic to the ports through certain IP address/machines. I tried to perform an idle scan in Nmap but it only takes one IP address as a zombie at a time.

Put the zombies' IP addresses in a file (say IP.txt).
And let's assume that the target machine

  192.168.88.135

Then you can use a script to automate the scan process.
Something like this

for ip in $(cat IP.txt); do
nmap -sI $ip 192.168.88.135 -p $1 >$ip.txt
done

After saving this script, and giving it execution privileges, you can invoke this script and pass the port you wish to scan to it as a parameter.

For example :

./script.sh 80

This command will attempt to preform idle scan on the target for port 80 using all the zombies you had their IPs in IP.txt and will save the result of each scan in a text file with the zombie's IP address.

I hope i got your questions right cause i still have doubts about whether this is what you want exactly.