Gather system metrics securely from infected VM I intend to train an RNN on snapshots of the VM metrics to classify malware. I will, therefore, run hundreds of different pieces of malware inside that VM. It has been isolated from my host (as best as I could/thought).

What would be the best (most secure for the host and most reliable for the information collected) way to gather regular (every second or so) snapshots of the system metrics (such as packets sent and received and process list) from an isolated Windows 10 VM where malware will be running?

The way to collect data should make it difficult for malware to interfere with it and not increase the risk of malware escaping the VM.
Until now, I was relying on VBoxManage (which is great) but processes and packets sent/received are not listed.

I am open to other virtualization engines than VirtualBox, if it helps.

I opted for Cuckoo to automatize running the software on the guest machine and wrote a custom auxiliary analysis script to collect those metrics every second. The way to collect data is thus as secure as Cuckoo is so I guess better solutions could be found but at least there is a possibility to stream them as they are collected so that, in case of loss of communication between the host and the guest, metrics prior the loss are not lost.


If I switch to LUKS on an SSD, have I just wiped it? I have been using an SSD with no system-level encryption. If I now switch to full disk encryption using LUKS + LVM, do I effectively wipe the old data, or is it still hanging around until overwritten?

No, the data is not wiped. It is trivial to make all data "disappear" by TRIMing the whole drive, but all the data are still on the flash chips and are only slowly wiped in a background process.

Fortunately, most SSDs are already encrypted in hardware precisely to avoid costly full disk wipes. Many consumer SSD brands provide utilities to reset the key which effectively wipes the disk. You can probably also send direct ATA commands using something like hdparm.


What can a user do in order to protect against CSRF attacks? If I'm browsing while I'm logged in into my hosting panel or router or any other application, there is a chance of being hacked by a CSRF exploit.

So, the question here is about user or client-side not server-side protection against CSRF attacks.

What can a user do in order to be safer? Maybe use two browsers, one for important accounts, another one for browsing?

Maybe use two browsers, one for those account, and another one for browsing?

This is a probably the best idea since it offers the most separation. This way classical session cookies will not be shared between sites, although a sharing of Silverlight and maybe Java or Flash based session ids might still happen. In most cases it will probably already be enough to start an instance of Firefox/Chrome in private/incognito mode.

But using another browser or browser profile for each sensitive site is not practical in all instances and one will probably do it only for some more sensitive sites like online banking or administration of the router. Apart from that valid cross site requests are in use for instance in single sign on setups (i.e. sign in with Facebook etc) or for using 3rd party payment providers like Paypal. For these cases there are several browser extensions which help dealing with CSRF and you will some examples at Wikipedia - CSRF - Client side safeguards.


What more can I do to secure my service? I run a multiplayer gaming service that provides a server list for clients and servers. At the moment it uses an SQLite database stored locally (which is insecure in itself). I am drawing up plans to convert it to either MySQL or Microsoft SQL Server in order to provide redundancy and also the ability to view real-time server statistics online.

Now, knowing that a single database is a disaster waiting to happen (plus it is a gigantic attack vector, too) I plan to introduce redundancy by:

Having two database servers, one for internal and one for web (web will be a slave to internal, but the flow of data will not be bidirectional);
Web database will be completely cleared and regenerated when data duplication takes place from the internal database;
Web will not have account information stored on it;
Non-default ports will be used and the firewall will be restricted to only allow specific hosts to connect;

Am I being over-zealous with my security precautions, or should I be adding more layers of security?

Some statistics that may influence any answers:

44.8% of players are Russian;
The service sees around 50 billion requests (admittedly they're small) each month;
There are around 50 new users each month, with this number steadily increasing (and will see a spike in a couple of months when I start advertising it);
It runs on AWS EC2 servers (I plan to use AWS RDS for the databases)

I suggest a more proactive approach as well by doing your own penetration testing against a non-production server setup specifically for this sort of thing.

We use BurpSuite's scanner feature to test our own products - it has really helped augment our quest to find vulnerabilities. ZAP is a free alternative I've heard good things about, but have not personally used it. Pay particular attention to any SQL injection issues they identify.


How to get result from airdump-ng on Ubuntu 18.04 LTS? Issue: when I run airodump-ng wlp3s0mon, no results appear.

I recently installed all kali linux tools on Ubuntu 18.04 LTS from this git repo https://github.com/LionSec/katoolin

My chipset is the following and it supports monitor mode

root@Dimitris:~# airmon-ng
PHY    Interface    Driver          Chipset
phy0   wlp3s0      ath10k_pci   Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31)

I tried killing all the conflicting processes and daemons airmon-ng check kill | systemctl disable avahi-daemon.service
I use my interface in monitor mode airmon-ng start wlp3s0
I've updated my system and I've updated my wireless drivers

Still airodump-ng wlp3s0mon fetches no data.

I literally tried everything I could think of.
What am I missing?

Bought an Alfa AWUS036NHA network-card and it works like magic. Apparently my internal network card wasn't compatible or something.


Can we have https without certificates? I apologize in advance if I am fundamentally misunderstanding something, but is it possible to have encrypted communication protocols (https, I suppose) without resorting to a certificate system?

This questions comes regarding the EFF/Mozilla initiative to "encrypt everywhere!" I understand that certificates verify /identity/ but is it possible and/or reasonable to build a https protocal witbout using verified identities? The most obviosyu example is communicating with self-signed cert sites, but are there other situations where you might value the encryption of the communication more that the identity of who you are communicating woth?

You can have SSL/TLS without certificates. This is supported in the TLS standard: the "DH_anon" cipher suites involve no certificate whatsoever. But you have to remember that such an unauthenticated TLS is inherently weak against active attackers, since they cannot prevent client or server impersonation (or both at the same time, which is called a Man-in-the-Middle attack).

Most Web browsers deactivate DH_anon cipher suites because of the inherent vulnerability to MitM. You can have the same conceptual effect with a self-signed SSL certificate, that you can produce yourself without talking to any CA. Of course, the same Web browsers will then show the "scary warnings", for pretty much the same reason.

From the EFF point of view, whose arch-enemy is the NSA, generalized DH_anon cipher suites would make sense, since Evil Spy Agencies™ are know to prefer passive eavesdropping (since it leaves no incriminating traces). Passive eavesdropping is defeated by DH_anon. However, for most other people, the biggest threat is not governmental intrusiveness, but mundane con-artists that try to separate you from your money, and these do not hesitate to run full MitM attacks, e.g. with fake WiFi access points.

The Let's Encrypt initiative aims at making certificate issuance free (as in "no money") and automated, while still maintaining a bit of effort at "verifying" that whoever obtains the certificate has some degree of control over the designated domain. From the look of it (it deserves closer inspection), this system relies on the DNS and implies that any DNS attack (e.g. DNS spoofing) might be leveraged into rogue certificate issuance, in a fully automated way, so this initiative would be a weakening of the current certificate model. On the other hand, if it convinces more people to use SSL, it contributes to a "safer World", at least from NSA-is-the-Devil point of view, where what matters is defeating passive eavesdroppers.

Anyway, without support from Microsoft and Google (i.e. inclusion of the Let's Encrypt root CA in IE and Chrome), there is no way that the initiative really turns into generalized HTTPS. Not a lot of people would activate SSL on their Web site if it means that 70% of users will get insulted and scared away by their browsers. If Microsoft and Google don't jump in the wagon (and I don't believe they will), then the Let's Encrypt system will remain a political gesture, but won't be widespread (and ultimately Mozilla will drop it if someone bothers to mount an automated DNS-based attack).

There is another completely different certificate-less mode for SSL; it is called SRP. That one is safe, but different from normal Web browsing. SRP ensures mutual client/server authentication with regards to a shared secret, and it does so in a way that protects the shared secret against offline brute force -- so it can tolerate the use of a low entropy shared secret, i.e. a password. TLS-SRP makes a lot of sense for accessing password-protected network resources, and it involves no certificate at all; and yet, it is safe against MitM and eavesdropping.

Unfortunately, Web browsers don't currently support SRP.


Why change password? Why are there recommendations to change passwords with certain intervals?

If I have a good password, e.g. a long wrongspelled odd sentence with a couple of special characters thrown in, why is the security compromised if I keep this password year after year?

To my knowledge there are two ways of getting trouble:

1) Brute force. Are there really such stupid systems still around that an attacker can try an enormous amount of passwords without any reaction from the attacked system? An easy protection  is of course to double the response time for each try.

2) An attacker gets hold of the password file and uses precalculated hashes to find a match in the password file.

None of these methods should work with a secure password regardless of how long it's been around so the question remains, why should I change?

There are recommendations to change passwords regularly mostly out of mindless repetition of a poorly understood practice from much older times in a different context.

Initially, passwords were something for the military; every single fort or camp used a "password" that soldiers had to know in order to enter the camp. We have indications that such a system was generalized in the Roman army, more than 2000 years ago.

Since such a password was, by construction, known to several people (at least the guards at the camp entrance, and every soldier who had business outside of the camp, e.g. to go fetch wood or water), and also uttered regularly and thus possible prey to spies with good ears, it was assumed that such a password would not remain secret for long. In fact, one could rationally expect that at any time, some enemies would know the passwords. The passwords were just a mitigation feature meant to delay covert entrance by enemies, rather than a reliable way to block them. The effectiveness of a given password steadily dropped over time, within a few hours, and thus had to be renewed daily.

Then the context changed. Nowadays, you use your password to authenticate yourself on a computer. There still are enemies, and they still want to learn your password. However, a very important part of the situation has changed a lot: you are, by construction, the only person who knows your own password. This is the normal, expected situation. On average, there is no leak at all. Your password is not shared. Therefore, the effectiveness of your password, which really is its secrecy, does not decrease over time -- it may drop to zero if the attacker succeeds at learning it, but as long as this does not happen, the password is as good as new.

Another context property which changed a lot is what attackers do when they learn a user's password. In the old Roman camp setup, the attacker would enter the camp, roam about it to try to gather intelligence (e.g. by listening around the centurion's tent), and possibly indulge in some casual sabotage, such as setting fire to supplies. This takes time. In a whole night, a spy can do some substantial damage, which is why there were extra mitigation features (other sentinels, rules against loitering within the camp, curfew, and so on). The regular password renewal forces the attacker to reacquire the new password while he tries to spread havoc. In our modern computer world, things don't go that way. The attacker will plunder your files and accounts, read and send emails, and generally enact his mischiefs within a few seconds because all of this can be automated to a great extent.

Forcing frequent user password renewal is a common practice of sysadmins, but it is misguided. Forcing your users to change their passwords every 42 days (that's the default value in Windows / Active Directory) makes sense only if we assume that the two following properties hold:

On average, at any given time, a non-negligible proportion of user passwords are known to evil outsiders.
Attackers loiter in the systems for weeks, and forcing a password renewal is a substantial hindrance to their nefarious schemes.

In reality, neither property holds. The forced password renewal, thus, does not yield its alleged benefits.

On the other hand, forced password renewal weakens security:

Users must generate and remember new passwords, which is harder, and promotes behaviours which are detrimental to security, such as writing the passwords down on pieces of paper, or sharing the passwords with colleagues.
The rate of "forgotten passwords" will be higher, increasing the workload of help desks. These, in turn, will react by lowering their identification standards, making them more vulnerable to social engineering.
Users will not like it, and they will be more inclined to see the sysadmin as a control freak, to be avoided or circumvented, rather than a helpful friend whose warnings should be heeded. Most of practical security relies on voluntary cooperation from the user base, and any unexplainable constraint on their daily work will severely damage their willfulness to cooperate.

To sum up, there are recommendations about password change out of misguided tradition. It is one of the myths which float around in the field of IT security, because sysadmins are people, and like all their other fellow humans they prefer to apply so-called "best practices" rather than making the effort to sit down and think.

The problem is inflated by how innovation is rewarded: in the field of security, innovation is tracked down, pursued, cornered and ignominiously slaughtered. If a sysadmin does "what everybody else does" and a problem occurs nonetheless, then he will not be blamed. However, if a sysadmin does a smart but novel thing, then he cannot expect any thanks; in fact, if an attack succeeds despite the novel system, the innovator will become the scape goat for the whole business.

You can read some other opinions on this subject in this past question.


Does Httponly cookie secures the sessions against xss? Assuming my apache version is higher than 2.2.x (I noticed in previous version the http only cookie can be found anyway) , does http only cookie secures the user session?

Is there any way the user get around the http only cookie in case of XSS to take control of the client information?

does http only cookie secures the user session?

Yes, that's the whole idea behind httpOnly.

But as you already mentioned, there may be other vulnerabilities which disclose the cookie. This may happen via vulnerabilities in the server (CVE-2012-0053 which you alluded to), via server misconfiguration (TRACE, although modern browsers do not support it), or via issues in the application itself (the session cookie may be exposed in debug functionality or in the admin backend; an example would be a call to phpinfo in PHP).

It should be noted that httpOnly only mitigates XSS slightly, and that there are various other attack scenarios with XSS that are (almost) as bad as stealing the session (such as CSRF - eg to add new admin users - , phishing, keylogging, reading out secret information, etc).


How can I be sure that I am using the real Facebook? I type www.facebook.com into my browser's address bar and press enter, then use Facebook.

Could I actually be visiting a fake Facebook even if I see a URL of https://www.facebook.com and a lock icon by the side of the address bar?

You can confirm that you're on the real Facebook by a variety of ways:

Inspect the certificate used to secure the site. Open up your certificate (instructions vary by browser) and see what it says - is it issued to Facebook? Is it in a valid time period? Now, look at who signed that certificate, again, turn a critical eye towards it. Make sure everything makes sense. Go down the certificate chain until you get to the root certificate. Now, go to your favorite search engine and check that none of the certificate vendors have been in the news for a compromised private key. Unfortunately, the CA based ecosystem means you have to just trust the root CA, to some degree.
Check the IP address you're connecting to - use your favorite NSLookup tool to see where your DNS is pointing you when you connect to facebook.com. Take that address to google, see if it matches what people commonly say Facebook's public IP address is.
See if other people have recently reported issues connecting to Facebook over TLS, or have any concerns. Consider if those concerns seem valid to you, or if they seem like the user is just doing something incorrectly.

Next, take all the data you've gathered from the above points, and any other reconnaissance you've done. Think critically about whether you think it's reasonable that all of the above has been faked by a convincing virus, evil malicious actor on your network, or Mark Zuckerberg having a laugh. Also consider that the issue you want to avoid (submitting or viewing information from Fakebook rather than Facebook) and think if it's possible that the eventual consequences (data leak) could happen in another way, such as a screengrabber or keylogger virus running and just recording your input into the real Facebook. Then, consider if the risk outweights the value you'd gain from logging into Facebook. Then realize that Facebook gives you no value and decide it's not worth the risk.


Multicore hacker tools? Have a school project coming up in multicore programming. I'm interested in/have used hacking tools alot before, and was wondering if there were any good tools out there that could benefit from being implemented in OpenMP or some other parallel framework to speed them up. I was originally thinking password cracking but saw John the Ripper, etc all usually have multicore implementations. Any ideas? Honestly anything would be appreciated.

Most tools used by hackers do not benefit from multithreading because they are not computationally intensive. The ones that do, in particular ones related to credential cracking, are often written with multithreading or even GPGPU acceleration in mind in the first place. So I don't think you'll find all that many tools that are written like that, since only a small portion would actually benefit from it.

One hash cracking tool that is not multithreaded that may benefit from it would be aircrack-ng.


Odd history of OAuth 2 device flow OAuth 2 device flow has an odd history. It's found in early versions of the RFC, but was then taken out seemingly without an explanation I could find. Recently, a new draft was proposed specifically to reintroduce it independently.

  The device flow is suitable for clients executing on devices that do
     not have an easy data-entry method and where the client is incapable
     of receiving incoming requests from the authorization server
     (incapable of acting as an HTTP server).

The other flows do not cover the scenario addressed by device flow so it has utility. Google supports it and has an example of it in action. Can anyone shed any light on why device flow was dropped from the OAuth 2 standard - are there security concerns we should know about?

I should just answer my own question after stumbling upon the reason - device flow was removed from the OAuth 2 specification:

  due to lack of sufficient deployment expertise at that time

Citation from Appendix A: Acknowledgements - IETF OAuth device flow draft #01.

Device flow is fairly common place these days. Some apps (e.g. HBO GO) on media devices (e.g. Roku) appears to utilize the device flow, where the device you're logging on to is decoupled from where you're entering your credentials. E.g. when setting up the HBO GO app in Roku, I get prompted to enter a code, which I get by logging into the hbogo site from my laptop's browser.


What are the TCP header features that are included in DoS buffer overflow? What are the TCP header features that are included in DoS attacks? Such as  service type: http, port: 80 and the count, and what else?

I want to know the features that determine the attack so I can write a code in Hadoop mapreduce to extract them from a log file containing TCP packets.

It varies according to the service and the attack. DoS attacks tend to fall into three categories; saturating the network connection (a.k.a. bandwidth flooding), overloading the service (a.k.a. application flooding), or overloading the firewall (a.k.a. firewall flooding).

Network saturation works by sending so much data to the server that it uses up all of the bandwidth, resulting in most genuine users (and most of the attacker's traffic) being unable to reach the server. This can be done in many ways; typically by sending large amounts of UDP or TCP control packets to the server. This will make it difficult for genuine users to reach any service on the network that the server is on, and make it difficult for data to get out of any server on that network back to the Internet. Such traffic can be relatively easily detected and blocked upstream, but as the source IP addresses are almost certainly spoofed, it's difficult to track down. The attackers don't need to actually create any network connections, so the traffic doesn't have to have real IP addresses. In a variant of the attack, the attackers spoof the server's IP address to send TCP SYN packets to non-existent services on thousand of servers on the Internet, who then send TCP RST packets back to the server.

Service overloading works by attacking the service specifically, using up resources on the service. This can be done in a variety of ways, but usually it's done by making lots of requests in a very short period of time, using up all of the resources on the server. This might be random logins or anything else that the service is vulnerable to. (Note that other attacks, e.g. brute force hacking of administrative accounts, may produce the same result.) This relies on real network connections, so the source IP addresses are real, but the machines are probably part of a botnet.

Firewall overloading works by opening lots of TCP connections, but not necessarily sending much in the way of data. Firewalls have to handle network connections between networks, and some come with security scanning functions. For the latter to work, they have to monitor the connections. This means that they have to keep details of the connection, and with limited resources, it is possible to use up all of the connections available by opening too many network connections; hence preventing the firewall from accepting any new connections until some of the existing ones time out due to lack of traffic.


Session fixation attack Given the following conditions,

Session ID does not change upon login
Session ID travels in form of HTTP cookie
There is no cross site scripting/redirection vulnerability on the login page

is it still possible to perform a session fixation attack?

First, please read upon session fixation attacks and make sure you understand how they work.  You didn't give us the information that is needed to determine whether standard session fixation attacks will work; all of that information is relevant to other attacks, but not to session fixation.

The fundamental characteristic of a session fixation attack is that the attacker manages to enroll the victim into a session that was previously established by the attacker.  After this, the attacker has control of a session that is now being used by the victim as well, which may enable the attacker to do all sorts of bad things.

The primary precondition for a session fixation attack to be possible is the attacker has to be able to force the victim to start using a session ID of the attacker's choice.  On some web sites, this is possible if the attacker can get the victim to visit a link like http://yoursite.com/?SID=1209023, because the web site will automatically assign the victim session ID 1209023 for the victim's future browsing on the site.  On other web sites, this is not possible, because the web site doesn't work that way.

So, you haven't given us enough information to know whether session fixation attacks will work, because you haven't given us enough information to determine whether the precondition is met.

That said, the site almost certainly has security problems.  It is vulnerable to eavesdropping (Firesheep-like attacks) and likely vulnerable to login CSRF.


how can an attacker access a system through a compromised router? Let's say an attacker gained access to the admin panel of a home router with port 21, 23 and 80 open.

I mean the attacker has full control over the router, thus being able to port forward, etc...

How could he gain access to the machines connected to this router?

There could be a few scenarios here that might work.

As you say above forward a port/bunch of ports from an internal host to the external IP address. Attack that IP.
The router itself has an OS, usually a cut down 'nix of some sort. If you could gain access to that then you would have one NIC on the Internal network. You could potentially use that as a spring board onto the internal network.
If the device supports it, set-up a VPN to a device within your control. It might be feasible to set-up routing between your network and the target network. Technically harder but could be done with the right situation.


Why is U2F not good enough to be used as authentication? In the context of low- and mid-security applications (ie, 95% of the web), why isn't U2F good enough to be the only factor?

As far as I can tell, U2F very securely implements the "something you have" authentication factor. There's many web apps where one factor is good enough, but we still have all the issues of using passwords (reuse, remembering them, etc). So why has nobody at all said anything about using U2F alone for authentication?

Here's the issue with U2F as being the only method of authentication: there is no verification that you are the rightful owner of the U2F device just because you have it in your possession. If U2F was the only form of authentication for everything, that would be like having one master key for your car, house, safe, safety deposit box, office door/building, and everything else. In our metaphorical situation, if someone stole that master key from you, they would have access to almost everything in your life.

Now, you may view my metaphorical "master key" scenario as being the same as a password, but this is the reason why people are encouraged to use several different passwords. Using different passwords is like having several different keys. Rather than having one key that unlocks everything, it's better to have different keys. If only one key is stolen from you, the thief only has access to whatever that stolen key works for. (e.g., if a thief steals your car key, he/she can only access your car.) This is still an unpleasant situation, but it's far better than that thief gaining access to everything you own. Likewise, people are encouraged to use different passwords so if a "thief" obtained one of your passwords, he/she would only have access to a limited number of your accounts.

Using only U2F is essentially comparable to using only one password for every website and using only one key for everything in your life. It's neither reasonable nor secure. As such, U2F should only be used as a second form of authentication in a two-step authentication structure.


Strange CA certificate prompt My network went down for a minute today, then this window popped up:

Can someone here clarify this for me? I was using firefox. I had google, youtube and outlook open. My name isn't even close to Daniel, nor a nickname of it.

I suspect your router rebooted. While booting, it redirected all web connections to it's local interface (eg. what is usually shown at 192.168.1.1). It has such invalid and expired certificate at https://192.168.1.1 During that brief period, you requested an https webpage, that was redirected to the router, which returned its cert and, as it is invalid, you got that prompt.


RaspberryPi3 wont show fake AP created by Airbase-ng Im using Aircrack-ng suite to apply an evil-twin attack with my RaspberryPi3 operated by Kali-linux on another RspberryPi3 with Raspbian Jessie.

The steps are as followed:

1.configuring the apache2 server details at /etc/apache2/mods-available/userdir.conf

2.configuring the isc-dhcp-server at /etc/dhcp/dhcpd.conf

my dhcpd.conf file:
authoritative;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.2.0 netmask 255.255.255.0
{
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.2.255;
        option routers 192.168.2.1;
        option domain-name-servers 8.8.8.8;
        range 192.168.2.1 192.168.2.20;
}

3.I have changed the NetworkManager.conf file so monitor mode wont interfer with the manager as follows:

[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[keyfile]
unmanaged-devices=interface-name:wlan0mon;interface-name:wlan1mon;

4.running:
airmon-ng start wlan1
airodump-ng wlan1mon
after choosing AP to duplicate : Dbest on ch#4 , running:
airbase-ng  -e "Dbest" -c 4 wlan1mon

At this point, im suppose to see "Dbest" broadcasting its ESSID to all of my wireless devices, although I only see the fake "Dbest" AP on the same device I have created it with(my kali-linux), as shown:

And on my Raspbian jessie I only see the original"Dbest" I am connected to and the fake one doesnt even appear, as shown:

After a quick check with iwlist wlan0 scan on the Jessie, the interface can "see" a network called "Dbest" and according to dhcpdcd panel addon "wireless and wired connections" The Pi can actually see the fake AP but I cant authenticate to it:

I have allocated IP and subnet Mask to the at0 interface created by airbase-ng, I have also enabled NAT routing options, dhcp listener, and the apache2 for the fake authentication though this has nothing to do with the problem.

Any ideas on how to make my fake AP visible?

both RaspberryPi3's has BroadCom BCM43430 wireless Chipset (wlan0)
My kali linux has USB input wifi adapter Atheros AR9271 wireless chipset (wlan1)
Everything is up-to-date, firmwares of the chipsets, drivers and my raspberrys are updated and upgraded.

You see two of the same SSID because they have different settings, to merge them and create an evil twin you need to meet some conditions, you need to have the same settings in both AP.

ESSID (What probe requests look for)
Encryption algorithm (Open, WEP, WPA, etc.)
Cipher (CCMP, TKIP, WEP40, etc.)

This is called WiFi roaming

Here's another question asking ALMOST the same:

Rogue EAP (PEAP) access point to obtain hashes

Try adding the option -z or -Z to airbase


Who tells that TrueCrypt is secure? Assuming you're not running on a compromised machine and you're following common recommendations (long random passwords, etc.), who specifically (name and affiliation) asserts that TrueCrypt is secure?

My name is an alias, and I am a professional paranoiac.

If you start from the philosophically cynical position that every piece of technology required to produce and distribute information is potentially compromised, then you will have difficulty accepting any current successful theory of information security.

Take the simple case of a desktop computer used to type an e-mail.
Keyboard: compromised
Hard drive: compromised
RAM: compromised
CPU: Compromised
Video Card: compromised
Network card: compromised
Network router: compromised

What would it look like to have a secure chain from at least your fingers to your ISP?

Keyboard: self made from simple momentary push buttons
Keyboard to computer interface: self made from individual CMOS logic gates
CPU: ...

And at that point you are screwed, because any modern technology is complex enough that it must be designed by and manufactured by people unknown to you and uncontrolled by and unresponsive to you.

This requires trust.

I must trust that whoever designed and manufactured the CPU is selling a uncompromised product. I can take steps to reduce the risk that the individual CPU that I purchase is compromised, but this then requires a theory of who is capable of compromising a CPU and what would motivate her to implement such a compromise.

The modern view of risk is based on a rough social theory about who attempts to do what and for what purpose.

Intel, AMD, and ARM, and other CPU manufacturers seem to want to make money. Compromising their own product seems to be inconsistent with their profit goal. The number of individuals capable of covertly compromising a CPU such that it would introduce an vulnerability allowing them to covertly intercept your data is small. The effort required to perform such a compromise is great. The value of a individual person's e-mail is small. There are other easier ways to obtain access to a person's e-mail than CPU compromise, so most infosec professionals consider mass produced commodity CPUs to be an acceptable risk.

So the argument goes with most computer components, because as it has been shown again and again it is really much easier to compromise a person at your office, or at your ISP, or you than to pull off some amazing covert feat of technical hackery.

The answer is that no one is guaranteeing that Truecrypt is secure, but they don't have to because Truecrypt provide more evidence of honest functioning than any CPU maker, and RAM or Flash memory manufacturer, or any computer retailer.

The source code is available for inspection by anyone at any time.

You can compile a binary from the source code and compare it to precompiled binaries.

Unintentional security flaws have been discovered in the source code and fixed.

And if you are happily typing away at a café with free WiFi and some adversary is running Firesheep and intercepting your traffic, it doesn't matter if your hardware is un-compromised and Truecrypt is secure. If your OS or browser software is vulnerable, or you connect to a poorly configured WiFi router, your information is vulnerable.


IP addresses readily available on black market? I know that criminals can readily find on the black market large dumps of password databases from hacked sites.  These may contain the username, password, and email address for millions of users.

But what about IP addresses?  Is it easy to find similar data sets that also contain, for each user, the last IP address that user used to log into the site?  Or, to put it another way, is it easy for criminals to get their hands on a large database that lists, for many IP addresses, an email address for someone who might have recently used that IP address?  By recent, I mean "in the past few years".

Suppose a criminal wants a large database that, for millions of users, has their email address and an IP address that user has recently used.  (This would allow the criminal to do a lookup by IP address and retrieve an email address for a user who has used that IP address.)  Is this readily available for sale on the criminal underground market?  Or is this tough/expensive for criminals to come by?

Context: I'm trying to assess the plausibility of a hypothesis about how some people might be getting phished by a specific attack campaign.  For these purposes, it would help to know whether it's easy for criminals to get their hands on large data sets that tell them not only usernames and passwords but also IP address information, or whether this information is not readily available to most garden-variety criminals.  In other words, this is effectively a question about the economics of cybercrime: what is the cost to a criminal of obtaining a database of (emailaddr,ip_addr) records, compared to the cost of obtaining a database of (username,password,emailaddr) records?

I do know about NAT and dynamic IP address assignment and their implications for this situation.

Is it feasible to find a list of user IPs used by an account? The answer to that is a "It depends on the user" answer.

The Effort Required

In a simple DB dump(those most common lists you mentioned with email,password) that list was often generated by an insecure page with an injection vulnerability. Often at that point the attacker doesn't have any console, file system, or other access. They merely obtained a copy of the table itself and that table more than likely doesn't store that information since it could be a many to many relationship, and usually exist on a separate intranet server if they do have that regional fraud detection in place at all.

A much more in depth, risky, and difficult attack would then be needed just to LOCATE the data. Then you need to attack to try and get the data. Often it isn't worth the risk unless you're expecting a huge payoff or have found horrible security practices in the first place. If the security is that horrible though it probably wouldn't be a system that even stores that information or has regional fraud detection systems in place.

The Alternative

A much more simple way to do it is to email each user a spear phishing email with something to make them make a request to your server to collect this information. This is a much simpler attack with a smaller payoff, but still a payoff nonetheless. It's easy enough to do on your own with just a simple email/password list and well designed enough phishing server with convincing enough pages/links.

At this point since it's so simple it's kind of a "If we have it we got lucky" situation, or a "DIY" situation. These systems are often complex, and sometimes offloaded entirely making the attacks to find that information hard to near impossible.


Is DWR (Direct Web Remoting) Secure? Is DWR considered secure, or what may be required to secure Direct Web Remoting?

Are there better options for hardened asynchronous communication?

DWR is reasonably secure if you use it securely. Anything can by made insecure through usage. You still need to validate all your inputs.


What should I do if I type my password in the address bar, or type password in google search? When someone accidentally types his or her password in one of the following three locations and presses enter, what should they do?

username text box
address bar
Google search

What do you suggest, for example, a checklist, or instruction note?

And what might happen to him?

If you accidentally disclose your password -- either through typing it into the address bar, or in any other way -- it's best to change it.

There's no need for any complicated checklist.  Simply change that password, everywhere that you used that particular password.  This will protect you.

Is it absolutely necessary to change your password if you typed it into the address bar?  Perhaps not -- in practice, the risk is probably modest.  Then again, why take a chance?  If you type it into the address bar, it may be disclosed in cleartext over the network. For instance, if you are currently connected using open Wifi, anyone within range of the network who is eavesdropping could capture your password.  Also, your password could potentially be captured in various logs.  So, at that point, rather than taking a gamble, the safest thing to do is to immediately change your password.  If you do that, you'll probably be fine.


Nmap: Spoofing IP adress (-S option) or using Proxy chains, what's the difference? I was reading Nmap documentation about firewall evasion here. I already know that it is possible to use a proxy to make a scan (with the proxy chains). But with the option -S it is possible to spoof an IP adress. Isn't it the same ?

Thanks

No.

Scanning through a proxy allows you to scan from the IP of that proxy, and it only works with certain scan types, as you're just tunneling traffic through a proxy server. Connect scans are the obvious example of a scan type that works via a SOCKS proxy.

Scanning with -S allows you to explicitly set the source IP address that your scan's IPv4 (or IPv6) headers contain. You can't do this with a proxy scan. If you're actually trying to scan something, the only useful reason to use -S is to set your source IP when nmap can't figure it out itself.

Alternatively, you can make it look like an nmap scan is coming from another system on the network, in order to confuse a defender and waste their time. However, since the target server will reply back to the IP address in the source header, you won't see the response packets from the server, so it won't function as an actual port scan and nmap isn't likely to return useful results.


How to secure backup scripts so I do not have to hardcode passwords? I have a secure and private aws ec2 environment but I need to do some backups of mongodb, postgresql, so I have a separate ec2 instance for doing backup and occasionally allow 80 and 443 to allow install/update software on backup instance.

I use shell scripts to do backup job, it requires hardcoded password or credentials in scripts, I don't feel it secure enough to have all credentials saved into one place -- backup instance.

How to secure backup instance to avoid saving passwords/credentials in plain text, I also want to avoid saving passwords/credentials in memory or temporary files?

Have you tried AWS Secrets Manager (or Parameter Store). It's built for exactly this purpose.

Create a separate IAM Role for the backup process, and grant the required EC2 instance that IAM role. Then modify your script to call Secrets Manager to obtain the credentials and and don't store those credentials anyway except in the memory of the running process. (i.e. purge it once the process is one).

In the background, the EC2 instance will have a metadata instance that issues tokens that the script can use to call Secrets Manager. Once it's able to call secrets manager, it can get the actual db credentials to call your DB. Even deeper, the meta-data service issues only temporary tokens for the IAM role, which makes this approach even better.

A more old-skool method, would be to generate the API Keys for the IAM role, and hard-code those credentials onto the ~/.aws/credentials location of your EC2. Then your AWS SDK will use it to call AWS Secrets Manager with the same concept.

Ultimately, the concept is the same, use an API key to call an API that returns the actual credentials used. That API call is logged (cloudtrail) and returns only those credentials necessary to the call.


Is it safe to connect to random SSH servers? In a nutshell: How secure are SSH clients? Can servers mess with them?

I saw this Ghost in the Shell bash remake today. Funny enough and there are a few movies (The Matrix, Star Wars, etc) that are delivered over SSH. There are also games that rely on you connecting over SSH.

But it occurred to me today that when we talk about SSH security, we're really focussing on the server; the transport security and authentication mechanisms, stopping brute force attacks and random remote exploits. What about the client? My client is running as me, it can do a lot of damage to a lot of local files... It certainly doesn't need root to hurt me.

What can an SSH server do that we might not expect? Is my client broadcasting data about me? Is there an exploit vector like a web browser?

2 options come to mind:

vulnerabilities in the SSH client
"hack back"

I run SSH honeypots, and a colleague wrote a script to take the password that the attacker used to create or change an account on the honeypot and use it to connect back to the attacker's SSH and enumerate the home directory. He has a 10% success rate...

This might be a corner case, but it highlights that once you make a connection to another computer, all bets are off. They know about you, your IP, and can use any information you provide against you.


Is the use of DSA keys a security risk? According to the answers on this question the differences between RSA and DSA would seem to be trivial.  However, according to this page DSA compromises your security if anyone is sniffing your packets when you use the key.  And according to this page, DSA is limited to 1024 bits.

If those claims are true, I can't see any reason to ever use DSA keys.  The policy of the company I'm working at, however, will only allow DSA keys.

What is the truth?  Is the use of DSA really reducing security as much as it appears to me?

You misread the page about sniffing packets; it is already paranoid and alarmist, but not to that point.

When producing a DSA signature, the signature engine works in a group which is embodied by a modulus p (a big prime number) and a group order q (a smaller prime, divisor of p-1). These values are part of the public key. For each signature, the signature engine must use a random number generator to produce a random value k which MUST be chosen uniformly in the 1..q-1 range. The "uniformly" term is very important. If the choice of k is biased, then it allows for key recovery after observing a number of signatures. Whether this is critical or not depends on the bias. A relatively small bias (e.g. k is generated as a sequence of bits of the size of q, then reduced modulo q) will incur an "academic" break with key recovery after about 263 signatures: an attack, yes, but not practical. On the other hand, if the random generator is so botched that it always outputs the same value for k, then two signatures are sufficient to recompute the private key. Sony deployed such an utterly failed RNG/signing system.

What this amounts to is that if the implementation of a signature algorithm is bogus, well, it may leak important data, including the private key. This is true of any cryptographic algorithm, and RSA is not exempt. Singling out DSA is unwarranted.

(What can be said in all neutrality is that DSA and ECDSA require a source of randomness for each signature, which is a relatively heavy requirement for embedded systems such as smartcards. Solutions exist; when I have time, I work on the issue. Edit: this is now a published RFC.)

As for key size, the current standard specifies sizes of 1024, 2048 and 3072 bits (that's the size of p). An older version of the standard allowed only 1024 bits, while an even older allowed all sizes multiple of 64 from 512 to 1024 bits. A number of deployed implementations of DSA are a bit lagging behind the 2009 standard, and thus allow only 1024-bit keys.

A 1024-bit DSA key is not a critical risk. As far as we know, DSA appears to be at least as strong as RSA with the same key size, and in practice a bit stronger. DSA relies on discrete logarithm and the current DL-break record is for 530 bits, while the current record for factorization (RSA) is 768 bits. Best known algorithms for factorization and DL have a lot of similarities, but the final step (where a lot of fast RAM is needed) appears to be more expensive with DL than with factorization. Thus, right now, a 1024-bit DSA key is not a true security risk. Especially since, for signatures, we have less to worry about future break than for encryption; and DSA is signature-only.

The main issue with DSA is that it is not as widely supported as RSA; when it is supported, it may have limitations (e.g. limited to 1024-bit keys, or usable in conjunction of only a limited set of other cryptographic algorithms). These limitations are not intrinsic to the algorithm, but reflect the state of the market, which is dominated by RSA. However, it is currently quite fashionable to switch to elliptic curve variants of DSA and, correspondingly, the market is slowly (very slowly) shifting towards more support for (EC)DSA.


Curious about best start for autoresponding Certificate Authority (CA) I am just getting started trying to implement some internal PKI ideas, where my app would need a cert to 'sign' messages.  Since this is all completly internal, we have some degree of trust, and I would like to have the client app able to present the csr [over the wire] to a CA which would then return a signed cert.

Are there any suggestions on the best way to get an internal CA solution like this?

Well you can make web API which will sign the requests (Java, C#), and run it over SSL (HTTPS).

The secure build running web based API for signing requests, with multi-layer security filtering (firewall) and access control (physical, network, application and human factor involved), in isolated network / cabinet with physical locks.

Definitely the app should run in something like C# or Java - not PHP. Static language is far more secure, C# or Java is very good choice for the big application server, while filtering and other can be even written in C++ or use the ModSecurity.

Also you need good cryptography on each security layer - not only SSL, but also SSL based access to database, certificate authentication in database like SQL Server or Oracle, database encryption. Also session token randomization (cryptographically secure RNG), password recovery security and so on must be protected with random/crypted token.

Finally the backup of the certs and the private key preferably on different non-accessible location with replication or handling via secure copy with ssh.

As it seems properly and easy way that would work with IIS on Windows Server in C# Visual Studio, which guarantees proper isolation and resilience / filtering, as well you can use SQL Server and it's crypto API. There is also very good framework for web based API with serialization and session.


Wiping a hard drive before reinstallation A few years ago, I left a new laptop at a sketchy computer shop to downgrade the OS to Windows 7.  The experience was a disaster. My goal now is to install Cinnamon Linux on the laptop and remove Windows entirely.
I put the Kaspersky .iso on a blank disk and ran it from the boot menu (I believe this is called a rootkit scan).  It detected several problems, including trojans:

(images show several objects detected, including Trojan.Multi.GenAutorunTask.a, Trojan.VBS.AutoRun.ag, HEUR:Trojan.Script.Generic, Trojan.Multi.GenAutorunTaskFile.a, not-a-virus:HEUR:AdWare.Script.Extension.gen, and other less serious objects)
Kaspersky appears to have removed all of the objects successfully. Are there any further steps I should take before replacing the OS to be on the safe side, or will removing Windows be sufficient?

The good part here is that you want to completely install a new OS. You don't need Windows to work or not be infected. In fact, you could fill the disk with random data prior to the Linux install in order to ensure nothing is left.
You mention that you are concerned about something there latching into the new OS. A virus installed on Windows affecting a clean Linux install on the same hardware would be extremely rare. Even for a clean Windows install it would be very strange to be affected, it is possible to store blobs in the BIOS that would then be loaded by Windows on install, or there might be a firmware virus installed. These are not things that would be even remotely likely to happen (probably not likely even if a foreign government wanted to spy on you), nor things that might be checked easily (or at all). Installing Cinnamon configured to wipe the existing contents would be enough to make that machine start from a clean state (other than getting new hardware).


What are the security implications of autorun and external drives? I have some questions about the security implications of accessing internal and external storage since I cant find any more information on it from what I've read. I have read about a variety of exploits (for example buffer overflows) and technologies designed to defend against them (DEP, ASLR, etc) but understand that no system is perfect.

What precautions can we take upon accessing external drive (manly to access media data) where we cant be sure about the safety of all datas contained?

From what I've read some good advice is to turn off autorun and have antivirus software activated. Does that mean it will then be safe to access any media file there? Or is there more to it? Would manually scanning the file before accessing it impact anything?

Secondly about internal drive; does Windows security and antivirus and other security software act differently when scanning an internal drive in comparison to an external drive?

For example, the feature to turn off autorun for an external drive - for internal drives does this mean everything could autorun unknowingly, hidden, etc?

The intention behind my question is to get input of more measures I can take to be safer. Is simply having an activated antivirus program, firewall, etc, enough or what further steps can I take to decrease my vulnerability?

From what I've read some good advice is to turn off autorun and have antivirus software activated.

The reason you'd disable autorun is to prevent the OS from following the contents of the autorun.inf file on the root of the external media to perform whatever action it is configured to do. Usually this is used for automatically launching software when media is inserted or connected, for example the software setup application when you insert the installation media for a piece of software. Ideally you would always have autorun completely disabled for all drives.

  Does that mean it will then be safe to access any media file there?

Nothing is ever completely "safe". There is nothing stopping you from running a file containing a virus or other nasty that your antivirus doesn't recognize and therefore doesn't stop. That said, the majority of media files are not natively executable, there are some exceptions like the Active Streaming Format (ASF) which execute content via a compatible media player but in general this isn't an attack vector.

  Would manually scanning the file before accessing it impact anything?

No - any modern antivirus solution will have what is called an on access scanner. What this means is essentially every time you open a file, it is scanned before it is executed (or passed off to the associated application to open).

  Secondly about the internal drive, does Windows security and antivirus and other security software act more loose on internal drive than external drive?

In general, no - there is no difference. The long answer is that this is entirely down to the feature set of your Anti Virus software and how you have your Anti Virus software configured, in some AV software you can configure exceptions, adding files or folders or drives to your exceptions list would prevent them from being scanned.

  Is simply having an activated antivirus program, firewall, etc, enough? what further steps can I take to decrease my vulnerability?

Regardless of the software you have installed "protecting" you, none of it makes up for user... naivety... Your concept of "enough" shows complacency, which is literally half of the problem.

The most important security measure you can deploy is common sense.

After common sense, keeping your applications up to date to ensure they're not the attack vector that gets exploited.


Protecting the remote database against tampering in a mobile app This is the first time I face a mobile app deployment at big scale. This app needs to connect to a remote server where to store and retrieve data.

I discarded connecting directly to the MySQL database as it would be a very bad idea, so I put some PHP scripts in the server side that receives data from mobile devices as HTTP POST queries and produces a valid response depending on the query.

Now I'm starting being concerned about security using this approach. Anyone may connect to their home WiFi and set as the gateway some local machine and start sniffing traffic, this way it would be very easy to know which queries are being sent and how to tamper some queries to get/send unathorized data.

To prevent it, I have considered the following approaches:

SSL: Seems obvious, but as far as I know, SSL will encrypt data in the wire transaction but still is able to be sniffed in a local machine.
Encryption algorithm: Encrypt both on the client and server side messages with some secure encryption. This would face some other issues, though, as hardcoding some keys in the app, which seems not a big deal.

I'd like to avoid using third-party add-ons and use my own code to do all the stuff, but at this point I'm stucked on how to procceed.

Any ideas? Thanks!

@Philipp is right when he says that you can't protect against your customer.

Instead of going to great lengths to keep the pseudo-queries secret, you should focus your efforts upon input validation and injection protections.  On the server where you take the pseudo-query and translate it to a SQL query, make sure that you're properly quoting any input to the SQL query, and perform basic sanity checking to raise the barrier against abuse.  A WAF could also help here, but if you're writing your application, you're in the right time and place to put proper protections in situ, which is even better.


Security of "secure messaging" services There are multiple vendors that offer so-called "secure messaging" services, designed to allow secure e-mail without the need for technology such as PGP, S/MIME or strict TLS between mail servers. The one I've been looking at is Mimecast's "Secure Messaging" service, but others are available.

Typically, instead of the content being embedded within the e-mail, it's uploaded to the vendor's servers, and the recipient is sent an e-mail advising them that they have a secure message waiting for them. The e-mail contains a link to a portal which allows them to view the content.

Access to the portal is via HTTPS. This ensures encryption during transit, which otherwise may not be the case if the content was embedded within the e-mail itself.

Access to the portal is protected via a username and password, which is designed to ensure the content can only be accessed by the intended recipient. If the recipient has not previously used the service, they are e-mailed a temporary password, which they must change after their first login.

Now, if the temporary password is delivered via the insecure channel (i.e e-mail), isn't that a flaw in the system? If an attacker was attempting to eavesdrop on the e-mail (presumably the threat this is designed to mitigate), then they wouldn't get the content, but they would get the password, which they can then use to access the content (assuming they get there before the intended recipient who would reset the password). Isn't that somewhat analogous to Alice sending Bob a symmetric key in plain text immediately before sending the cipher text?

I appreciate that the risk only applies when:

It's the first 'secure message' sent to that recipient as they will have set a password after that
The intended recipient has yet to log in and reset their password (may never happen if they never read the message)

So, am I right in my identification of the flaw, and is it just a limitation of the design, i.e it has some limitations in exchange for ease of use/flexibility?

I did wonder whether the Mimecast service has an option to allow you to deliver the password to the user over a separate channel (e.g phone) to improve security, but I haven't seen anything like that in the documentation so far (I've yet to actually trial it).

The presence of some security controls does not make a system secure.

Yes I think you have identified a valid problem but that organization could still truthfully say the confidential data was never sent in an unencrypted fashion.

Unfortunately there are many vendors touting things as being secure because they either have some security controls or because they can protect from one particular attack vector and if the consumers aren't asking the tough questions they are unfortunately unaware of the shortcomings in any given solution.


Are tracking cookies illegal? I have a merchant website. When a user visits the website, a cookie is set. Then when the same user visits the site again, we provide him with suggestions, content that he may enjoy based on what goodies he has viewed previously.

In my opinion we don't do anything harmful as content advice that the user may enjoy is all we do, using tracking cookies. But as far as I know, in the EU it's illegal to use cookies even for this (not harmful) purpose.

Is there a real risk of being prosecuted when using tracking cookies for not harmful purposes? What countries prohibit tracking cookies besides the EU?

This document outlines the changes in the EU cookie law, and things you need to pay attention to:
http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/~/media/documents/library/Privacy_and_electronic/Practical_application/cookies_guidance_v3.ashx

From my understanding of the content, the important thing is gaining the users' consent when storing a cookie on their computer. The two exceptions are:

(a) for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
(b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

covering vital things such as session cookies to allow the user to stay logged in from page to page.

What I've seen a lot of sites doing is have a popup on the first visit (usually inline somewhere in the page) explaining that the site needs cookies to function, blah blah, here are the cookies we wish to set, do you accept, yes/no.

It seems to be all about informing the user and gaining their consent.

P.S: I am not a lawyer.


Is long-term validity definitively corrupted upon TSA certificate revocation? Suppose a document that was signed with a long-term signature (e.g. CAdES-A): D S T1 (D - document, S - signature, T1 - time-stamp created using a time-stamping certificate C1).
If C1 appears in the TSA's CRL, is there a way or a time period (an opposite of "grace period" from RFC 5126) to still recover the long-term validity of the signed document (e.g. by quickly time-stamping it with a new valid time-stamp)? Or is the validity of all documents time-stamped with this revoked certificate definitively lost in this case (unless the document was re-stamped earlier)?

(Of course, the document could have been double time-stamped by two distinct TSAa, but this is rarely done.)

When a certificate is revoked, the CRL contains the revocation date which tells at which date the certificate became "invalid". Indirectly, it specifies that the certificate was fine up to that date. For instance, if a private key is compromised after a burglary, the security camera recordings will be used to determine at which hour the key was stolen, and that will be the revocation date specified in the CRL.

If a TSA certificate is thus revoked, the archive validity can still be verified as long as a time stamp from another TSA covers the time stamp from the revoked certificate and specifies a date which is anterior to the revocation date. E.g., consider a chain which works thus:

Time stamp S1 claims that the signature (and signer's certificate and so on) existed at date T1.
Time stamp S2 claims that the signature (and signer's certificate and so on) and the time stamp S1 and the TSA certificate for S1 and associated CRL and so on, all existed at date T2.
And so on.

If the TSA private key used to sign S1 is compromised, or the TSA hit bankruptcy, or any similar situation, happens at date T', then the archive is still safe as long as T' > T2: thanks to the time stamp S2, one can validate S1 as if the current date was T2, and at that date the TSA was fine and the time stamp already existed.

For extra resilience, you want to use two distinct TSA with interleaved overlapping time stamps:

Time stamps S1, S3, S5... are from TSA A.
Time stamps S2, S4, S6... are from TSA B.
You always apply time stamps in pairs. When the top-most time stamp is Sn and either of Sn-1 or Sn approaches expiration, you obtain two time stamps, from A and B, and thus increase the chain to length n+2.

With such a scheme, a discovered compromise of either A or B can still be recovered from, because in the chain of time stamps, you can "skip over" the rotten time stamp.

(Cryptographic details are relatively intricate; one important point is that a time stamp, as per RFC 3161, is a CMS SignedData with an explicit signed attribute which contains the hash value of the data that is time stamped; it follows that time-stamping an encoded time stamp is also an indirect time stamp for the original data. If that was not true, then you could run into cryptographic trouble about exclusive ownership, namely that a signature value is not necessarily as good as a hash. When you understand what I mean here, you will know enough to implement CAdES-A archive validation.)

The "grace period" is another mechanism for improved resilience. Its premise is that compromises are discovered after the fact, but usually not long after the fact. Applying a grace period of one week (for instance) means that you allow yourself to wait for one week, in case a past compromise is discovered. If after one week things still seem fine, then you begin to assume that though a compromise may have happened in the last five minutes (and you would not know of it yet), the situation was most probably clean one week ago. With time stamps obtained at the right moment, this can give a lot of extra resilience, at the expense of added complexity.


Is Django's built-in CSRF protection enough? Django sets a CSRF protection token on the user's machine via a cookie. It then asks for the token on POST requests. If these two don't match, it returns a 403.

If I change manually both the cookie and the token value I send in the request, the request is accepted. Django does not verify that the token value was set by the server. As long as cookie and request match, it won't return a 403.

This doesn't seem safe. What if another website spoofs my domain and set a new cookie and then sends the CSRF token value of the new cookie in the request? Django will compare the two and consider the request legit.
Are they any packages that implement this differently or am I missing something?

Django is using a Double-Submit Cookie and it is accepted as a safe method of CSRF prevention. Why?  Because, It is impossible for an attacker to control the cookie filed in a CSRF attack.  A CSRF attack is relying on the fact the browser manages cookies,  and will include cookies associated with a target domain to the forged HTTP request. It is possible to read and modify the non-HTTPOnly cookies using XSS,  however, almost all Anti-CSRF measures can be undermined by XSS.

To answer your question:
Yes, Django's CSRF protection system will prevent a CSRF attack from succeeding,  so as long as the application isn't vulnerable to XSS.


How to connect to AP when attacker is deauth'ing my device? Scenario is: attacker is disconnecting devices using aireplay --deauth command on AP so none of my devices are connecting to AP. Then what do I do now when none of my device is connected to AP?

Fighting interference is difficult. These frequency bands are unlicensed, which gives everyone the same right to use them (subject to regulatory rules regarding power limits, etc).

There are devices like WIPS (Wireless Intrusion Prevention Systems) which can help you. I think they could be expensive for a home use. Anyway, they are able to detect and prevent this kind of attacks. There are different DoS attacks. Yours seems like this one (but there are more):

802.11 Deauthenticate frames can be used to disconnect an individual station, or every station associated with a given AP. Sending a continuous stream of these forged frames is known as a Deauth Flood

Most WIPS can recognize these DoS attack signatures.

There is a wonderful article explaining all of this and from where I taken some info: How to prevent DoS attacks. Read it carefully.

If you can't get a WIPS, which is understandable, you can try to "fight" it configuring your AP with different ESSIDs on different channels as a workaround. I know is not the best solution but it works. You can do this only if your AP support multiSSID (or if you have more APS).

If you set up 4 different networks on different channels and you configure all of them on your devices, after being kicked from one, you'll connect automatically to other. The attacker needs to setup another different attack for the other channel, so he is not going to be success if he is not able to send 4 attacks at the same time, which usually requires 4 different wireless devices to perform the attacks.

All of this is assuming your DoS attack is bassed on death packets on which the attacker needs to set a channel on its monitor mode card to perform them. If you are suffering other kind of DoS attack, then this workaround maybe couldn't work. But the most common DoS attack is this "deauth framing" so maybe can work in your case.

Good luck!


Resetting password upfront, before getting email I recently reset my password on a site that had me enter the new password I wanted to use upfront at the same time I said what email I wanted to reset it for. Then all I had to do was click the link in the email it sent me and it was reset.

I think I actually like this better and may implement any future reset password forms I have to code this way, but I'm just wondering if there are any security issues I should consider with this method (that aren't already present with the traditional method)?

This is not as secure as one might want it to be:

Assume an attacker visits a site and pretends to be some user of that site and to have fogotten the password. On the password reset page they can pre-enter the desired future password and a mail to the real owner of the account is sent.
The real owner receives the mail and perhaps clicks the link because

they didn't have their morning coffee yet
for anti-malware purposes they have an automatism that
automatically GETs any links in mail to pre-scan the content
they think they didn't request a change, but now that the mail is
in, it might be a good idea to actually change the password on the change form they expect behind the link
any other reason

Now the attacker's password has been validated and they can access the account accordingly. Of course, the victim could initiate another password reset to limit the damage to a few minutes, but the average user would not think of that. Also, the attacker could initiate a second reset as well and how should the victim decide which of the mails arriving shortly is the right one?


How are one-time password generators like Google Authenticator different from having two passwords? Google Authenticator uses the TOTP algorithm to generate your One-Time Password (OTP). TOTP works like this : The server generates a secret key and shares with the client (you) when the client registers with the server. Using the shared key and the current timestamp, a new password is generated every 30 seconds.

If anyone has the shared key, then they can generate the OTP themselves using the TOTP algorithm. Isn't this similar to a password? Doesn't it get reduced to having two passwords - One is the password that you use to login and the other is the shared key between you and the server?

Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.

The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.

** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.


RADIUS for WPA2 Enterprise in Cloud? This is about securing WiFi APs which are usually connected to broadband like DSL and Fibre. Some of them are at business site and some are at home.

To protect against Evil Twin attack (basically spoofing AP, stealing password and then breaking into LAN etc) there's seems to be a way - to introduce WPA2 Enterprise with EAP-TLS.

Now the thing is that some enterprise users do not have private clouds nor resources or space to put a small server or VM Instance to serve as RADIUS server (even they have, it is very often difficult).

So I am wondering if solution with RADIUS server on the public internet in Cloud would be something reasonable to implement?

Going by this path I found one online service serving this purpose, I think it's suitable for the home users and small businesses - see IronWifi

I believe this way the WiFi network can be then commissioned as safe to use. Is that correct? Would be there any sort of attack (with EAP-TLS) which can be deployed to circumvent this security in reasonable easy way? Like using standard hacking software / hardware?

All routers have been already setup to 11n mode by the way and 20MHz bandwidth. This is to make it more secure by using newer standards but because it is using 40MHz by default I have made it 20MHz so that I could zone them better.

The security of the system really depends on whether the service provider is trusted. When you deploys EAP-TLS, the private key of the RADIUS server must be stored in the disk, or at least in the memory, of the service provider's server. If the service provider is malicious, there are many things it can do to compromise the key.


Can spambots access pages available to only registered, authenticated users? I have a web application where users register and are activated via an email sent to the email address they supplied.

Then there are pages that are only visible to registered users (non-user access is restricted by checking for a User Object in the session).

On these restricted pages I would like to display a listing that includes the email addresses of other users.

Do I still need to take precautions to obfuscate the email addresses so that they are protected from spam bots and the like? Or is it enough that the page isn't accessible to non-authenticated users?

Edit: The emails on my site are not particularly valuable and it is not a site with very sensitive material. I just don't want the users to be bothered with spam.

There are a lot of individual points here. First, let me clear up a few things:

I personally, consider email addresses Personally Identifiable Information (PIN) and thus needing to be protected. My personal rule of thumb is that if I am asking a user for it, then it is not already known and thus needs to be protected.
Obfuscation may not always prevent data leakage (emails) but may only slow down or slightly deter the process (but only if implemented properly)
I assume you have a secured web application and are only asking about if you can reasonably assume safety on pages where users have properly authenticated.

The quick answer is yes (assuming the web app and auth have been implemented properly).

There are important things to consider though:

Automated 'spambots' can and do infiltrate many systems with authentication mechanisms. For instance, your app as defined merely validates that a registered user has a valid email address, this is easy enough to work around.
Make sure you implement your authentication processes properly. IE make sure your process to check for the 'user object' is cryptographically secure. without more details on how you do this, I cannot say for certain.

A simple alternative to displaying real email addresses of the users would be to use an email relay service (like craigslist does) or an internal messaging system.


Password stretching using concatenation of hashes I'm working on a simple file encryption tool.

Basically, here's how my program works:

password = get_user_typed_password()
salt = uuid4()
key = bcrypt(password + salt)
cipher = AES(key)

for block in input_file:
    output_file.write(AES.encrypt(block))

My question is about "how could I make a possibly short and weak password a long and strong one?".

I thought I could use a concatenation of sha512 hashed, like that:

for i from 1 to 1000:
    password += sha512(password).digest()

At the end, I would have a a 64000 long password with 'high ANSII' characters like these ones: ☼¢♣┌¥↕▼║ÅÕ¼■♫.

Do you think it's a good idea to stretch the given password like this?
Remember that it will not be stored in a db.

I know that inventing your own mechanism is bad, but here, it's only for making the password longer/stronger...the final key will be key = bcrypt(long_password + salt) anyway.

With that question, I wanted to ask one that I didn't found here:
"Hash concatenation is bad for generating a key...but what about password stretching?"

Thanks in advance for your answers, explainations and critics (I'm a newbie in crypto)!

"Long" does not make "strong". What matters is the entropy, a tricky word which means "that which the password could have been". A weak password is weak because it is part of a small set of possible passwords. The attacker is in your head; when you select a raw common English word he knows that he just has to try all common English words; there are about 10000 of these.

Now suppose that you have "stretched" your password. How many distinct stretched passwords can you end up with ? Still 10000. The attacker still has only 10000 passwords to try in order to break into your system. The stretching has make the passwords longer but not stronger because entropy has not changed.

At best, you can try to make each attacker's try as expensive as possible, and that's the role of bcrypt.


AWS credentials seem terribly insecure. Why? In my ~/.aws/credentials I have the following:
    [default]
    aws_access_key_id = <something>
    aws_secret_access_key = <something-else>

This file has permissions 0600 but doesn't require anything from me if you walked up to my computer, typed on my keyboard while my back is turned, you could have these values by copying them to a thumbdrive, copying them to /tmp and grabbing them later.
With ssh I have keyfiles, but the private key requires a passphrase to use it.  I can do ssh-add which will store this in memory and allow we to use ssh all day long without typing the passphrase every time.  Admittedly,  using ssh-add does lower the security on my machine to that of the AWS credentials, but if I reboot, security is back in place.  If my machine dies and it has to go to the shop, my ssh keys are still safe, but my aws credentials aren't.
Why is this acceptable?
Why didn't AWS use an ssh type setup to begin with?
Why do I need 2 factor on my AWS login if this plaintext version of my keys is sitting on my computer?
Seems like there are 2 padlocks on the same door but the door is only pushed closed, not actually "locked".
Are my concerns overblown?

I know some people create ssh keys without passphrases, something I think is foolish, and something that essentially boils down to this same security-minus AWS mechanism.  I'm not one of those people.

I'd like to invoke The 10 immutable laws of computer security. The scenario you describes falls under #3:

If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

Yes, the barrier to a passphrase-protected ssh file is higher than to the plaintext AWS credentials, but only very marginally. As has been said in the comments to the question, someone with physical access to your computer can do far, far worse things to your security than stealing some revokable credentials.
So, the answer is: They are perfectly secure. Your machine should be well shielded and not run untrusted code. If it does, any further protection than the 0600 permissions won't help you. The credentials are in plaintext because adding layers of encryption on top does not add any real security, it only complicates implementation of clients accessing these credentials.


How to validate CSRFGuard token on the server side? I have implemented the OWASP CSRFGuard library to protect my application against CSRF attacks. I'm using the CSRFGuard JavaScript file and servlet to inject CSRF tokens in all the Ajax requests. So far I'm seeing that the token is being properly added to all requests.

My question is how to validate that this token is valid and recognized by the library on the server side? I can get the the token to the server side but I have nothing to compare with. My concern is that an attacker could inject any value and the app wouldn't know if this is valid or not.

I have deleted and altered this token from requests and noticed that the filter is not rejecting them, so I assume that the validation of this token is something that I have to implement in my servlet, right? But how? I have looked at the CSRFGuard classes but haven't found any that stores the token generated by the JavaScript servlet.

After exploring the code for a couple weeks trying to find a way to validate the token on the server side, I found that it is stored in the HttpSession session variable. Look at the fetchCsrfToken method from the JavaScriptServlet class .

Based on that, I'm validating the token at server side as follows:

String CSRFToken = request.getHeader("OWASP_CSRFTOKEN");
if(CSRFToken.equals(tokenValue)) {
    // Code to execute if the token is valid
} else {
    // Code to execute if the token is not valid
}

I hope this is helpful to others who use the OWASP CSRFGuard library.


Should I concatenate root certs I am installing SSL cert and I am in doubt about should I concatenate site cert, intermediate cert and root cert or just site and intermediate cert ?

TL;DR Concatenate all but root.

It's only required to concatenate site certificate with the intermediate certificate. If there is more than one intermediate certificates you need to concatenate all of them.

The "root certificate" is the last certificate in the chain - it's the last because it is self-signed, and no other certificate in the world could verify it.

Concatenating root will work but is not recommended. The properly implemented client-side software (web browser) cannot ever trust a root that it received from your site. It must ignore it. It has all the valid roots in its trust store and there is no use to ever trust a root that is distributed over an insecure connection from a random site.

If a user wants to except your site from certificate validation, there is also no use for them to add your root certificate to trust store. More than likely that user is not aware that they open door to nearly all their SSL connections (except pinned ones). They should only ever trust your site certificate (aka the leaf certificate).

The popular ssllabs.com test site issues a minor warning in case a root is concatenated, describing the connection with something like "contains anchor".


Is it possible to USB whitelist in Linux? After watching Black Hat's presentation on the fundamental problems with USB "security", I'm wondering if there's a way to do USB whitelisting in Linux.

Is there currently a mechanism that will allow only a certain list of USB devices to actually load drivers and run on latest Linux kernels?

USB devices are normally identified by vendor and device ID, and, in Linux, support for USB devices is handled with udev. You could write udev rules to reject all devices, save for a specific (white) list. See for instance this question.

However, this might not bring the security you wish. Indeed, all devices of a specific model from a given vendor will share the same ID. If you allow, through your whitelist, a device with ID 08e6:3438, then any device that claims to have that ID will be allowed as well. An hostile device can perfectly announce whatever ID it wishes to show. To have a real whitelist, you would need each single device to contain a specific identifier that the attacker cannot guess (i.e, a key). There is nothing of that kind in existing USB protocol and devices.

Such a white list would be, in any case, redundant with physical control. As the tangible human user in front of the machine, it is up to you to decide whether you will or will not insert a specific device in the USB port. If you want to insert a given device that you have in hand, then you can alter the rules to allow it; and if you refrain from inserting the device, then you don't need the whitelist either. USB device filtering would be most useful in situations where untrusted users can access the physical ports. This is, arguably, a pretty bad situation to begin with, since this means that untrusted users have some level of physical access to the hardware. This might apply to self-service kiosks in photography shops -- but in such cases, the untrusted user is supposed to bring his own USB device, thus whitelisting ceases to make sense.


How to Prevent Copying of Device Source Code in Manufacturing Suppose you are going to mass manufacture custom circuit boards and would like the manufacturer to upload the device firmware onto these boards before shipping them out. What are some security systems/methodologies/features you would put in place to prevent the theft of firmware IP in order to prevent counterfeit devices?
In short, my goals are:

Upload a binary image of firmware to circuit boards in the assembly line
Prevent the manufacturer from being able to "sniff" the binary being uploaded to each device

It's not that easy, but you could use 3 manufacturers, each one completing part of the process.
One may etch the board and put the passives, other gets the bare flash ships and flashes the firmware, the next one would solder microcontrollers already with the firmware.
This isn't a guaranteed way to prevent copy, but makes non trivial to do so. The first one will have all the board plans and passives, but not the controllers. The second will get a binary blob and no idea what is that about, and the third just finishes the almost done board.


Updating stored, encrypted containers on a server My scenario is this -- I want to store an encrypted container on a network server. This encrypted container should be accessible to others to download and decrypt/mount locally provided they have the key. If the container is ~64MB (random example size) and I mount it locally, add a file, and then unmount... Is there a way to upload only the changes to the encrypted volume (I'm assuming the md5/sha1 hash changes after you drop a new file into the container) to the server and change just those portions of the container, without having to re-upload the entire container each time?

A close enough solution is Rsyncrypto.

Rsyncrypto is a utility to encrypt files in an rsync-friendly fashion. The rsyncrypto algorithm ensures that two almost identical files, when encrypted with rsyncrypto and the same key, will produce almost identical encrypted files. This allows for the low-overhead data transfer achieved by rsync while providing encryption for secure transfer and storage of sensitive data in a remote location.

Rsyncrypto is a modified encryption scheme. It is based on industry standard AES for symmetric encryption, as well as RSA for having different keys for each file while allowing a single key to decrypt all files. It even uses an encryption mode that is based on CBC.


Generic error message for wrong password or username - is this really helpful? It is really common (and I would say it is some kind of security basic) to not show on the login page if the username or the password was wrong when a user tries to log in.
One should show a generic message instead, like "Password or username are wrong".

The reason is not to show potential attackers which usernames are already taken, so it'll be harder to 'hack' an existing account.

Sounded reasonable for me, but then something different came on my mind.

When you register your account, you type in your username. And when it is already taken, you get an error message - which is not generic!

So basically, an attacker could just grab 'correct' user names from the register page, or am I wrong?

So what is the point about generic messages than? Non-generic messages would lead to a much better UX.

No, you are correct that at some point during efforts to prevent attackers from determining valid user identities you will either have to lie to them or provide exceptionally vague error messages.

Your app could tell a user that "the requested username is unavailable" and not be specific as to whether it was already in use or just didn't meet your other username requirements (length, character usage, reserved words, etc.).  Of course, if these details are public then an attacker could work out that their guess failed due to the account being in use and not due to invalid format.

Then you also have your password reset system.  Do you accept any username/email address and say a message was sent even if that account wasn't in your database?  What about account lockout (if you're using it)?  Do you just tell the user that their credentials were invalid even if if they weren't but instead their account was locked out, hoping they contact customer support who can identify the problem?

It is beneficial to increase the difficulty for attackers to gather valid usernames, but it typically is at a cost of frustrating users.  Most of the lower security sites I've seen do use separate messages identifying whether the username or password is wrong just because they prefer to err on the side of keeping users happy.  You'll have to determine if your security requirements dictate prioritizing them over the user experience.


Password management in Firefox, Chrome and Safari I just read a couple of very interesting discussions on Chrome password security strategy.
Chrome’s insane password security strategy
Showing stored passwords - Tim Berners-Lee
The following is how Chrome, Firefox and Safari handle storing passwords and showing stored passwords:
Chrome uses OSX Keychain to store passwords in encrypted form.
In Chrome, you can go to the password settings page and with one click you can see your passwords.
Firefox doesn't uses the OSX Keychain to store passwords in encrypted form.
In Firefox, you have the option to use a Master Password (not enabled by default). You type the master password at the beginning of every new session and every time you want to view stored passwords.
Safari also uses the OSX Keychain to store passwords in encrypted form. However, in Safari when you want to see the passwords, you need to enter the KeychainLogin password. (It is a 'fake' measure, because Keychain doesn't actually require authenticated applications to enter the KeychainLogin password to retrieve the passwords stored by them. This can be seen when Safari retrieves the passwords on website login prompts without the need for KeychainLogin password.)
Given new sessions of Safari and Chrome and a malicious user who doesn't know the KeychainLogin password. Safari is, in effect, no secure than Chrome because the user can just change the type of the password field to text using the inspect element tool and see the password.
My question is:
1) Given an attacker who doesn't know the Firefox master password and a new Firefox session (which hasn't asked for the master password yet), how easy/hard is it to see the stored passwords?
2) If the firefox master password is different than the OS user account password, does knowing the user account password change anything?
I am asking this because in one of the above discussions the security tech lead of Chrome says:

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.
Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.
We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

There are two related but distinct issues here: that Chrome can retrieve passwords without extra authentication, and that it displays them upon request. Both Elliott Kember and Tim Berners-Lee confuse these issues.

That Chrome is able to retrieve passwords without prompting the user is inherent in using an operating system facility to store the passwords. It's up to the OS facility to arrange to authenticate the user or prompt for an authorization at the time the password is requested, or not. Encrypting stored passwords is no more the job of the browser than to provide file storage or a network stack: this is done by the operating system and benefits all applications, not just the one browser. Users can configure retention and access policies in the keychain application, and those settings can apply to items stored for applications other than Chrome (other browsers, network shared storage, FTP, SSH, PGP, …).

Tim Berners-Lee seems to be arguing for browsers to implement a password encryption feature on top of the operating system's. That's bogus: why would a browser do that? Firefox does it because Mozilla does it because Netscape does it because it was written for primitive operating systems that didn't have such a feature. There is also an advantage to the browser implementing its own password storage, which is that a profile can be copied between platforms complete with stored passwords. This is to be balanced by the downside of the browser implementing its own password storage, which breaks the expectations of users who believe that their secrets are protected by the operating system. If I'm entering passwords in OSX, I'd expect them to be stored in my keychain, protected by the same protection as the keychain (on-disk encryption with a master password, inaccessibility when the screen is locked, …). If my browser doesn't use this protection, that's an unexpected breach of trust from its part.

If a browser is to store passwords, it must be able to retrieve them. If the browser can retrieve them, so can any other application. So when Elliott Kember complains that “there’s no master password, no security”, this is plain nonsense. The passwords are already in the keychain, and any application can retrieve them. Chrome is not breaching any security here: it's honestly representing what information is available. Elliott Kember claims that the lack of choice is “deeply misleading”, but that's completely wrong: Chrome has no more choice to be able to access the passwords than you have a choice not to be able to hear when someone is telling you something in a loud voice. You may plug your ears and sing “lalalala” loudly, but that won't change the fact that you would be able to hear.

Elliott Kember acknowledges that “the computer is already insecure as soon as you have physical access” and “that’s just how password management works”. Well, precisely. Chrome is being transparent, which goes exactly against his claim that “Google isn’t clear about its password security”. Chrome is being perfectly honest: it can access the passwords and it does not hide this fact from users.

Elliott Kember is advocating for Chrome to provide users with a false sense of security. It is well-known that a false sense of security is the enemy of security. Justin Schuh has it right.

Tim Berners-Lee makes another point. He acknowledges that retrieving passwords is possible, and it can be done by downloading a simple application if none of the software installed on the computer can do it easily. However, he argues that this capability should not be made easily accessible in a legitimate-looking application, because that makes it look like looking at someone else's passwords is somewhat legitimate.

While this makes sense, it doesn't really hold water. If you're digging around somebody else's profile, you're clearly snooping. Somebody's password is no more confidential than their browsing history. Non-technical people are rather more prone to sharing their password than their browsing history, and that was already the case before Chrome.

The one security measure that Chrome should implement is not to risk accidentally disclosing passwords when the legitimate user is in control. And it's already doing that: you have to click a button to show each password.

So Chrome is doing it right. Keep doing what you're doing.