Is a threat model totally subjective or can it be based on objective guidelines? We all know that in the security field everything depends on the threat model, which basically means you need to define who or what you are protecting from. But who should decide this, and on what objective basis? Since you can't protect everything from everything, you need to choose the most likely threats and focus on those. But I think it's difficult to assess the likelihood of a threat without making subjective decisions, and I don't know if there is a method or collection of best practices that can help.

I'm asking this question because I realized I can't decide what to protect from. It's easy to say "don't open attachments from suspicious senders", but who decides who's suspicious, and how exactly? It could be defined as "anyone not in your contact list", or "anyone as long as they aren't from [insert your favorite rogue country here]", but that seems very subjective to me. If I don't trust my browser I might use it inside a VM, if I don't trust the VM I might use it in an air-gapped machine, if I don't trust the machine... well, it never ends, so again, who decides what I should trust and on what basis? Or for example, how do I know if I should even protect from the government, if I'm likely a target? It might look like there's only a thin line between a threat model and paranoia, but at least real paranoia can be diagnosed. The doctor checks some symptoms in an official book, and makes decisions based on that (or at least he should). By analogy, if there was an objective method to define threat models, the doctor would open his book and be like, "Yes, China is officially considered a rogue country as far as infosec is concerned, so in this case you should definitely reject email coming from there", or "No, in your situation you should just trust the software in your distro's official repo; if you don't trust it then you might be paranoid and might have to take these pills".

"don't open attachments from suspicious senders" is not the kind of thing you would put in a threat model.  The threat is what may be in the attachment.  It's a threat no matter who sent it (and don't assume that it came from the specified email address).

Also, there's a difference between identifying threats and mitigating threats.  Yes, the hardware may be compromised, and you can identify that in your threat model, that doesn't mean that you actually do anything about it.  Basic risk management: avoid, mitigate, accept or transfer.  At some level, everyone accepts risk.  It's unavoidable.  Identify your most likely threats, figure out your budget.  For each threat, figure out the cost to avoid, mitigate and transfer and then determine if the cost is inline with the risk.  If it is do it, if it's not then accept the risk or get a bigger budget.

Finally, budget isn't always about money, it's often time.  If your #1 risk takes ten times longer to mitigate then your #2 and #3 combined, but your #1 risk is just slightly riskier than #2, which is slightly riskier than #3, then accept #1 and deal with #2 and #3.

There is no formula for this, it's about judgement.


hardware required for wifi security system i am planning to implement one WIFI security system , in which one can lock or unlock door remotely.

As i have serched over internet and i came across
lockitron and schlage

Now what i want to know is

1) the physical setup required to implement this project.
I mean what hardware i will be needing to implement it ?

2) Is it possible to use RFID locks which can also be locked and unlocked over internet ?

A quick glance at the lockitron web site answers both questions.

The hardware setup involves replacing existing locks with their WiFi connected locks; and they support NFC but not plain RFID.


TCP / UDP port monitoring programs for mac? Does anyone know of a free and effective port monitor for mac? Also, can a laymen, in relatively short order, learn to use such software to detect and thus prevent unauthorized remote access/control of their system?

Littlesnitch is well worth a look. It's not free however there is a 3 hour use limit at which point you need to restart the filter.

There is  also  a Lite version of GlowWorm but only supports Tiger.

Or HenWen, an OSX GUI for Snort.

I would pay for Littlesnitch if it were me, $30 US.


Multi-factor authentication - email link I'm trying to understand possible issues with the approach of sending the MFA one-time-token to the user as a clickable link in the email.

Instead of submitting the OTP on the web page, user will simply click on the link and web application should be able to proceed with the application flow.

I have seen most of web applications use user submitting approach.

I would like to hear the community thoughts on clickable email link approach and any known web applications use that approach for MFA.

This is not multi-factor authentication, as it's just "something you know" twice (the password to your service, and the password to the user's mailbox -- and knowing user habits, they will be exactly the same). Further, the email from your system to the user's mailbox is not likely to travel over a secure connection, as we still live in the world of opportunistic encryption for mail delivery. So, the "secret token" is being sent over not-so-secret channels.

This is marginally better than just asking users for a simple password, but this is definitely not multi-factor authentication (which is supposed to prove that the user has in their possession a specific hardware device).


How can trace if someone successfully remotely accessed my Mac? On my home network, I have a headless mini-mac that I use as a media, plex and security cameras server. I had screen and file sharing enabled, so that I can control it from my regular iMac, since no mouse, keyboard and screen is connected to mini-mac. It is connected to my home wifi and also to my regular mac via thunderbolt connection.

My router had port forwarding enabled for that mini-mac so that I can access cameras from outside.

Yesterday, I was working on my regular mac when suddenly my screen moved to the "login screen". I also noticed the screenshare icon was connected and when I hovered over it, it was my mini-mac ip address. I tried to shut down everything ASAP, mac and mini mac, then restarted and disabled screen sharing and remote login on the regular mac.

What steps do I need to take to confirm or rule out, via logs and queries, that someone was able to:

Gain access to my network
Successfully log into my mini-mac
From mini-mac, successfully gain access to my iMac
If any of the above items, for how long until uncovered?
If they were able to access files, programs, etc.

Basically, I want to assess if indeed I was "hacked" and if so, to what extent.

Thank you!

So your home network should be something like this:

                                          +--------------+
                          Cameras<------->+  Cam server  +-+
                                          +-------+------+ |
                                                  |        |
                                                  |        |
+--------------+     +--------------+   wifi/eth  |        |
| The Internet +-----+ ISP's router +-------------+        | Thunderbolt
+--------------+     +--------------+             |        |
                                                  |        |
                                                  |        |
                                          +-------+------+ |
                                          |     iMac     +-+
                                          +-------+------+

Analyze

  Gain access to my network

You want to check the network logs of the following 3 endpoints:

The router (Port 5900, 5901)
The cam server (Port 8000, 8001)
The iMac (thunderbolt Connection activities)

If you remember when the event occurred, and you know how to read a pcap file you can diagnose what happened.

  Successfully log into my mini-mac

On your cam server, check the entry of those log files (App/Utilities/Console):

/var/log/osxvnc.log

/var/log/secure.log

/var/log/system.log

  From mini-mac, successfully gain access to my iMac

On your iMac, check the entry of those log files:

/var/log/system.log

Typing last & last username in the command prompt might show some useful info.

Additional information

A VNC server can be bruteforced, look at this example using metasploit and vnc_login module. For preventing it, You can add one of those 2 security layers:

Adopt a strong password policy with 12 characters as minimum length.

  the use of both upper-case and lower-case letters (case sensitivity)
  inclusion of one or more numerical digits inclusion of special characters, such as @, #, $
  prohibition of words found in a password
  blacklist
  prohibition of words found in the user's personal information
  prohibition of use of company name or an abbreviation
  prohibition of passwords that match the format of calendar dates, license plate numbers, telephone numbers, or other common numbers

  source wiki

Step up a level by not using a login/password Authentication.

You can find a walkthrough here

Edit 1 : A successful attacker with enough privilege will delete some log entries ( if he knows what he is doing)

Edit 2, (answering comments) :

  Also, what specific info should I look for in the logs ?

router: Time & Ip address, Ask yourself those questions:

Which IP address has connected to my network when i was home ? You also want to know the global IP address you use when you remotely connect to your home network (favorite coffee shop IP, Workplace IP, Mobile Phone IP...)
The odd events occurred at time xx:xx, is there any entries in the router's log corresponding approximately to this time, or few hours before ?

iMac & Minimac: You first need to find a suspicious entry in the router's log, note this suspicious entry timestamp somewhere, then search in the Mini-mac's system.log what occurred at this time. Do the same process with your iMac via sudo last username command.

  How would I be able to retrieve more items for last command?

Let me introduce you a famous acronym in the IT world, called RTFM : Read the Fine Manual. look here


Using sqlmap and testing parameters inside SEF URL alias I would like to use sqlmap and set parameters, that are concatenated inside the URL parts.

I know that a following URL is possible to track with defining of parameter by putting an asterisk behind the parameter value:

sqlmap -u http://example.com/article/22565*/

But what about URLs, that have numbers and alias strings concatenated all together?

I would like to test, whether injections can me made on this URL:

  http://example.com/alias-text-22565/description

A bold number is a dynamic parameter. This parameter is read on server side using regex.

How to define parameters inside URL, so sqlmap knows what are the real parameters in this manner?

Note: Currently I am not capable to test a website with SEF URLs rewriting switched off.

AFAIK it should work out of the box as sqlmap keeps the values, however, on the chance that it doesn't work, here are some easy work arounds that come to mind:

You could tweak the url by appending an injection to be more sql injection friendly to begin with, ie: http://example.com/alias-text-22565-(case when 1=1* then 1)/description as described here: http://pentestmonkey.net/blog/exploiting-a-tricky-sql-injection-with-sqlmap. This is the method I usually use, but it does require you to have some knowledge of sql injections.
You could feed sqlmap through an intercepting proxy such as burp or zap and add a replace rule to replace 22565 with alias-text-22565 and invoke sqlmap with the url http://example.com/22565*/description
You could write a quick tamper script that would prepend alias-text- to the url and invoke sqlmap with the url http://example.com/22565*/description


Is displaying remaining password retry count a security risk? Some websites display a remaining password retry count when I input wrong passwords more than twice. For example, displaying that there are 3 retries remaining until locking out my account. Is this dangerous from security perspective ?

Locking accounts is a bad idea in the first place.  It might seem like you're making your organization more secure by keeping out "bad people" who are "guessing" at passwords using brute force attacks, but what have you really solved?  Even with this policy and a perfect userbase who never makes security mistakes, an attacker can perform a denial-of-service attack on your organization by repeatedly using the password "aaa" to lock out the accounts of critical users.  Consider what happens if your attacker gets a copy of the list of usernames for your entire IT department:  Suddenly, IT itself — the organization that would otherwise be able to unlock other users — is itself completely shut down.

Always consider what the threat model is before implementing a policy.  A "bad guy" determined to hurt your organization will find alternative attack vectors.  Your lockout policy won't even faze a nation-state actor (like Russia or China or the NSA); a determined hacker will just find other ways around it (like social engineering); and it will only hurt legitimate users of your service, no matter how low or high you set the lockout counter.

Moral of the story:  Don't lock out accounts.  Instead, do what Apple does with the iPhone:  Each login try doubles the login delay, so that after a dozen failures or so, you have to wait one hour between each successive attempt.  That's long enough to prevent "bad guys" from performing brute-force attacks, but still short enough that a legitimate user can spend that hour figuring out what their password was and typing it in properly after lunch — or contacting IT and apologetically asking for help.  (Similarly, "flooding" policies can often be implemented at the IP-address level in your firewall, not just at the user-account level in your software, if you're concerned about a dedicated attacker trying to brute-force many different accounts.)

And if you don't lock out accounts, you don't need to have a counter — or display it.

[see also: this excellent answer on a similar question]


How to be mean to some people that stole my phone My iPhone was stolen a couple of weeks ago and I started receiving the following messages on my recovery secondary number that I provided with Find My iPhone:

The URLs are:

https://apple.inc-view.us/?auth=3455
https://apple.inc-locate.us/verify.php?ID=&auth=325&vr=

And they mimic the interface of Find My iPhone where they're asking me for my Apple ID credentials. I logged into Apple ID and the phone hasn't registered since it was stolen.

Wondering if there's something I can do to track them down or be mean to them.

Offensive defense is the type of attack you are looking to perform. You have been the victim of a technological crime, you are the target of a phishing campaign, and you want to get even. This is a very normal response and I can tell you that many organizations, governments, and individuals attempt this on their own daily. There is a major issue with any type of non-legal recourse, however.

Due to the anonymity of the internet, and the relative ease of using a botnet to do malicious activity, it can be really difficult to assure that you only hurt the people you intend to hurt. In attacking an individual through a network relay, you may end up shutting down your own grand mother's computer which is less than ideal and totally irrelevant to the initial attackers. The only truly legal recourse is to co-ordinate with your local authorities and attempt to gain information back on the attackers.

If you can glean any information from your cowardly attackers that may indicate name or location you can use this to work with the authorities. Also, if the phone is on, you can still attempt to use the "Find My Phone" feature to track down it's current location alongside the proper authorities (I do not recommend confronting thieves on your own or without legal support).

In the end, it really sucks that you're in this position and I have compassion for you. Know that your options are limited, but do take advantage of the ones you can so you have the peace of mind knowing you did all you could legally do. That will be far better than putting your self in the position of risking jail time over a device.


How to interpret SELinux boolean allow rules? I'm trying to understand what permissions are allowed by some of the SELinux booleans for httpd domain, as it is my main source of concern, and the current policy of my organization is to give truly the least privilege required for getting an application working.

Reading with sesearch what some booleans do, it's clear I don't really need some of them, so they we disabled them. In example, we don't need nginx being able to connect to squid, ftp, gopher and memcache ports, among other things the boolean httpd_can_network_relay allows, because we pass our requests through sockets. Boolean httpd_can_network_connect its too broad for us, as the only port we need open, it's already labeled for redis and we have a very easy to understand policy module for that: https://security.stackexchange.com/a/172569/162749

I've struggled a bit to get some PHP scripts working, even after labeling carefully some public paths, in order to just allow writes from the webapp on uploads and caches for captchas directories, but not letting that upgrade magically by itself or download from third parties scripts that could be executed. Also, just allowing execution of scripts in specific paths.

I've already got this goals working and people outside from IT are working without complains, but I can't quite understand completely yet what the booleans I've had to enable are allowing, because the man pages are useful for quickly enable something but not understanding how the magic works. And the output from sesearch its just too confusing.

For example: sesearch -AC -b httpd_anon_write lets understand that only is allowing writes in public_content_rw_t labeled objects, but I still don't get why it was not working with httpd_sys_content_rw_t.

But, output for booleans httpd_unified and httpd_builtin_scripting are conflicting, and I'm frankly worried to allowing without need too much things. Specially on httpd_sys_rw_content_t labeled objects I couldn't get the writes to work without enabling both booleans, and I didn't enabled httpd_enable_cgi because permissions seem to broad for me. See the most confusing part:

DT allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]

ET allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_builtin_scripting ]

Maybe it's that I don't get where is the AND and if there it is an OR, but I don't get why all operations are allowed according to the former rule, just enabling httpd_builtin_scripting, and why according the first rule, must be enabled that same boolean, AND httpd_unified AND httpd_enable_cgi.

Honestly I would be more than happy to not depend on any boolean that allow more than what it is strictly necessary, that's why I'd be grateful to get a hand helping me to understand the syntax of the booleans needed for a rule to be enabled.

FWIW, the webapp I'm securing is WordPress based, and the tutorials all around are depending on booleans without explaining why they are needed and what risks they introduce. My organization has a distaste for automatic upgrades for compatibility breaks too.

What exactly is your question?

Basically what i think sesearch is trying to tell you is that you have two options if you want to allow httpd_t type associated processes to "read write" httpd_sys_rw_content_t type associated "files"

Either you set these three:

httpd_enable_cgi
httpd_unified
httpd_builtin_scripting

Or you set this one:

httpd_builtin_scripting

Which obviously does not quite seem to make sense since the former is a super set of the latter. The policy author may or may not have made a mistake there.

The former set of booleans may have the same rules as the latter boolean as part of broader permissions. Your query was quite narrow and so it matched both scenarios

You could use sesearch to see what rules are associated with each of the booleans and then determine whether setting the first three or setting the latter one is in your favor

Granted that this seems to not be very intuitive, but sesearch gives you accurate and to the point info.

The web server policy used commonly by distributions aims to be a general purpose policy, and that makes it pretty complex and introduces some trade-offs. There are many different way's to use web servers. The booleans, and types give you some flexibility but if you want to have a policy that is tailored to your requirements then you can always choose to write your own policy for your web server. Unfortunately that might not be as easy as it should be but it is possible.

As for why things "did not work for you", I would have to see some AVC denials to be able to interpret the events and suggest solutions.


Is it possible that same IP shows up in Gmail even if the hacker is reading my emails? Is it possible that same IP shows up by clicking in the extreme downright corner  "Details” button in Gmail even if the hacker is accessing / reading my Gmail. If Yes, how to prevent this.

Although you did not provide that much information,
the only way the hacker reading your emails would have the same IP as you is if he is accessing your email through your computer/network.

A few things you can do:

Make sure no one is on your WiFi other than authorized devices (as in devices you expect to be connected).
Run an anti virus scan to see if any malware is installed on your computer
Make sure any remote tools you are using are secure (do they all have a strong username and password?).
Make sure it is not anyone from your family/friends that are in your house or even on your computer.

If after doing all the above the hacker still can access your email, using a device you know is clean reset your email password and then restore your computer.

Note: If your computer is in fact infected you should assume the hacker has all your credentials from any site/services you use.


Are there security or privacy concerns in using YaCy as a substitute for Google or Duckduckgo? The concept of YaCy of decentralized web search seems smart. Does anyone see any flaws in its design that may lead to additional exposures of privacy or security compared to the usual alternatives or there are only advantages?

Wikipedia mentions some disadvantages but if I didn't get it wrong they don't seem directly related to privacy, security or anonymity.

I would be concerned with search poisoning (as mentioned in the wiki). If search results are coming from peers, you will not know how valid those searches are. This means that a malicious peer could redirect users to non-valid sites for phishing or browser infection.


Admins running Powershell from their desktop instead of server What security issues are presented by letting server admins in a corporate environment run PowerShell scripts from their local desktop rather than from the server?

I am not a server guru by any means so I am curious what potential security issues this poses.

If it's a dedicated admin workstation and admin account then that is the ideal scenario. So admin uses his regular account and regular pc for email & web browsing. And the admin uses his admin account and admin pc for powershell scripting against other systems.

Also don't forget to enable powershell logging so that you have a history of the commands executed in case an account is compromised.

Also make sure you apply least privilege to admin accounts. In many cases an admin can accomplish his powershell commands and queries without requiring local admin privileges.


Is it insecure to send a password in a `curl` command? Here’s an example request we can make to the GitHub API:

curl 'https://api.github.com/authorizations' --user "USERNAME"

This will prompt for the account password, to continue:

Enter host password for user 'USERNAME':

If we don’t want to get the prompt, we can provide the password at the same time as the username:

curl 'https://api.github.com/authorizations' --user "USERNAME:PASSWORD"

But is this method less secure? Does curl send all the data at once, or does it first setup a secure connection, and only then send the USERNAME and PASSWORD?

Regarding the connection there's no difference: the TLS is negotiated first and the HTTP request is secured by the TLS.

Locally this might be less secure, because:

The password gets saved to the command history (~/.bash_history) as a part of the command. Note: This can be avoided by adding a space in front of the command before running it (provided you have the setting ignorespace in variable HISTCONTROL).
On a shared system, it will usually be visible to others in ps, top and such, or by reading /proc/$pid/cmdline, for as long as the command is running.
Storing the password unsecured in a script might pose a security risk, depending on where the script itself is stored.


What exactly is CTF and how can I as programmer prepare for a CTF with beginner-friendly people? I reached out to an old friend of mine who was a terrific programmer back in my school days and he invited me to attend one of the CTF events with his university group.

This group seems very beginner friendly and open to everyone, but I still fear that I have not nearly enough knowledge in the security field to be able to participate. So I would like to prepare a bit for it, find out exactly what this is and what I can do to improve to a basic level. Internet research just gave me a very vague idea of what a CTF is.

What I already have is basic and intermediate knowledge in some programming languages including C#, PHP/Javascript/etc (basic), C (very basic), Java. I don't know if this is of any use, but I thought it can't hurt.

What exactly is a CTF and how can I, as a total beginner, prepare for a CTF event on my own?

CTFs (Capture The Flag) are like courses within games. Some website provide easy ones to learn the ropes, with simple challenges of increasing difficulty. For example http://overthewire.org/wargames/ will teach you how to use tools (Hex dump, vi, even the terminal itself) with each challenge.

The main goal is usually to find some code, either embedded in a file (stegano), hidden in a file inside a server where you will need to abuse a known vulnerability (regular CTFs), or even exploit a program's source code to find a secret password (reversing).

Just like any programming challenge, take your time, learn the tools, and don't be afraid to look for help or writeups (obviously not on the CTF you're trying to achieve), but they can provide insight on tools to use, depending on the type of challenge.

Some links :

https://www.hackthebox.eu/ : Various categories of CTF as explained above, ranging from easy to hard, lots of writeups

http://overthewire.org/wargames/ : Mostly regular CTFs with a file hidden in a server, and specific rules to find/decrypt it. Good for beginners, will teach you the basic tools


In what situations can SSL keys be "forged" and what does that mean? Quotes from @devknoll referencing Patribotics:

  Not a mirror. It's signing SSL using same certs as http://wikileaks.org for goodness sakes.

Do mirrored or load-balanced sites not share the same SSL key? Is the author claiming something like: "If a site that isn't Wikileaks, appears to have the Wikileaks SSL private key, something shady is going on?" Or have I misunderstood? The author is referencing that when they did a dig wikileakgs.org the below two of the IPs linked to that domain were called into question (note: I don't understand why, hence the thread). (Edit re: these hosts added at bottom of thread.)

wikileaks.org.          600     IN      A       141.105.65.113
wikileaks.org.          600     IN      A       141.105.69.239

I'm confused by both statements:

  Best case scenario, keys aren't physically there (but bad actor can still forge)

  Worst case scenario: Bad actor can decrypt anything. If WL was your bank, this server can take money

Is this because they appear to have a SSL key that they shouldn't? How does one tell if a web server is a separate entity, and not just load-balancing (on behalf of Wikileaks, as in this example)?

Edit--

One big issue, that I can identify, is as follows: Wikileaks is hosted by Swedish ISP Bahnhof, in the Pionen facility. However, when users did a whois 141.105.69.239, they got this response:

organisation:   ORG-MTL21-RIPE

org-name:       Mir Telematiki Ltd

org-type:       LIR

address:        Barabannii pereulok 4/4

address:        107023

address:        Moscow

address:        RUSSIAN FEDERATION

phone:          +7 495 369 9796

fax-no:         +7 495 369 9796

mnt-ref:        MTLM-MNT

mnt-ref:        RIPE-NCC-HM-MNT

mnt-by:         RIPE-NCC-HM-MNT

mnt-by:         MTLM-MNT

abuse-mailbox:  abuse@hostkey.ru

abuse-c:        HA2800-RIPE

created:        2010-10-06T10:46:46Z

last-modified:  2016-09-30T12:14:19Z

source:         RIPE # Filtered

I am now thinking, that this host being owned by a Russian provider (who Patribotics associates with Russian hacking communities -- potentially an entirely separate issue), and not being owned by the Swedish ISP or a reputable CDN... perhaps is the issue?

Do mirrored / load-balanced sites, not share the same SSL key?

A mirror site usually refers to a server with a different hostname which mirrors the information located at the original server. But I think you are referring to the case where different servers share the same hostname in DNS. In this case it is common that they share the same certificate and thus key pair but it might also be that different certificate (with different key pairs) for the same hostname are in use.

But, commonly servers sharing the same hostname in DNS are managed by the same entity which owns the key pair. In this specific case this might be different, i.e. different parties managing the servers. In this case sharing the key would not be a good idea for security reasons. But there are not enough information  if this is really the case here.

  Best case scenario, keys aren't physically there (but bad actor can still forge)... Worst case scenario: Bad actor can decrypt anything. If WL was your bank, this server can take money

I think they are assuming here that the servers are managed by different parties but use the same certificate.

The worst case scenario is then that the secret key is shared between all these parties so that they can use the same certificate. This means that any of the parties could also hijack any of the traffic by the other server if the same certificate is used. While this does sound bad it might not be that bad if the key is only used for this certificate and if the information on all sites are the same anyway and if no sensitive data are sent by the client which  others should not see. This might actually the case for wikileaks.

Another option to deal with this case is to not share the private key but to defer part of the SSL handshake to a single party which has the private key. See keyless SSL from Cloudflare for more details on how this can be done. In this case the private key is not shared but the above man in the middle attack against any other site with the same certificate can be done anyway. The main advantage is that there is less chance that a party gets compromised and thus the private key leaks to yet another party.

  How does one tell if a web server is a separate entity, and not just load-balancing (on behalf of Wikileaks, for this example)

You cannot tell from outside. A separate server is a separate entity in any case but you don't know if it is managed by the same or another person and even if it looks like all servers have the same content there might be subtle differences or they might serve completely different content tomorrow.


Are SMS,MMS stored on the network service providers' servers? Are SMS and MMS sent via a mobile phone stored on telecommunication service providers' servers before passing them to the recipient?

Does it depend on the country or does every network service provider have the resources to do something like this?

The telecommunications service provider (your cell phone company) has to transmit the SMS and MMS messages to their recipients; so yes, the provider has to store them, however briefly.

Most providers retain messages for varying, not-so-brief, periods of time.

Search [sms carrier retention period].


How can other information be added to my credit card? I have had cards skimmed and then used: my credit card was being declined every time I used the magnetic strip, but it worked fine when I used the chip, so I assumed that the strip had been deactivated.

I found out that my magnetic strip contained information from a completely different credit card!

Does anybody have any idea how this could have happened? I traced my steps back, and I only used it getting gas at the pump, which I don't do anymore, and once at a flea market from a vendor who used an Ipad with a device on it.

I called Capital One's fraud department, and they said it's possible for a device to not only record your information but it could actually add information to a magnetic strip; unfortunately, they no longer keep the information on magnetic-strip fraud because they don't use them anymore.

The magnetic strip on a card is pretty similar to the tape in a video cassette, and doesn't have any particular resistance to being wiped or rewritten, other than generally requiring a stronger magnet due to the specific composition of the material used. Given a suitable writer, therefore, it's possible to write arbitrary data to a card stripe. You can pick up a writer from online stores easily.

Most mag-stripe skimmers can pick up all the data on an inserted card easily enough - historically, they were then used to create dummy cards - so getting the data to write isn't a particular problem either.

The main question therefore is "why would an attacker write different card details onto your card?". I suppose if you wanted to muddle up the trail for investigators looking into card fraud, having multiple people generating transactions for a single card could work, but it also makes determining that it's been cloned easier (can't make in person transactions at locations 100 miles apart within 5 minutes!). Doesn't seem a great reason to me!


Is it safe to share your password security plan with others? The recent epidemic situation has given me enough time to reconsider my password security seriously. I have devised a detailed plan for how to use elements such as a password manager, 2FA, U2F keys, etc. in conjunction with each other to create the optimal security architecture for my personal use (according to my rather limited knowledge of information security).

Now, the plan grew to such an extent that I decided to write it down as a document, so that I remember how certain parts of it work, why they are designed in a particular way, the weak points and so on. Is it safe to show this plan to, e.g. a friend who is also interested in strengthening their security? What about a hypothetical, extreme version - to share it online?

According to the Kerckhoff's principle, the security of a system should not depend on its secrecy. That's what I had in mind when designing my plan. I believe that anyone competent enough to try to break my system would also not be obstructed by the lack of knowledge of the design. Its strength relies on secret keys (and some informed use of MFA), also in agreement with the principle. However, I have seen on this site that sometimes users are scolded if they reveal a lot about how they organise their security in a question.

We can easily find how AES or public-key cryptography work in a few moments. That doesn't prevent them from being widely used and considered safe. Would the same reasoning apply to my personal scheme?

There is always some risk involved because your method might have some flaws, and if an attacker can easily know all the details of your implementation then, of course, they have an advantage. To reduce the risk, some obscurity is sometimes used as an extra layer of protection in case something goes wrong, and as a deterrent. Here are a few points you can consider to evaluate the risk:

Who are you going to show your plan to? Friends? Coworkers? Security auditors? Haxxor forumz? The whole internet via social media?
What advantages do you get if you show somebody your plans? Are you going to get valuable opinions? Do you really need more opinions? What is your goal when you publish your method? Would you like it to become a widely recognized standard or common best practice?
How confident are you that your plan is already good enough? Are you aware of the current best practices? Have you tried to follow them?
How flexible is your system? Is it already in use? Is it still in the design stage and could be modified relatively easily? Or is it hard to change anything in the process?
Who are your enemies are what assets are you protecting? If the potential damage is severe and the probability of advanced attacks is high, then, of course, you will need to be more careful.

Answering those questions might help you figure out if it's worth sharing information with other people, and if you are increasing the risk or reducing it. So for example, if you are unsure about your practices, you'd better share your methods before you start to use them, to hear opinions from trusted experts (for example asking about your methods in this community). But if you are part of a team of security experts that works for the government, maybe you'd better shut up instead of publicly twitting about every detail of every security control your agency is using.

OPSEC best practices can be summarized as "shut up unless you really need to speak". In your case, it's probably OK to share your method with your friend, to help them improve their security. But posting that information publicly on Facebook would be bad OPSEC, no matter how secure your method really is.


Are some uncommon TCP ports scanned less than others? Ignoring the top 5-10% of port numbers for common services that are the commonly targeted by port scanners (i.e. ports 22-ssh, 23-telnet, 80-http, 139-smb/cifs, 443-https, 3389-rdp, etc.), are the balance of the port numbers scanned in a statistically random way?
In other words, for a random IP (i.e. the IP of someone who is not the target of a directed attack) are there ports or ranges of ports that are more or less likely to be scanned?

Are there any honeypots that keep track of statistics on port scans of random IPs?

The way attackers go about portscans is to first target those with known exploits or commonly weak protection.

The list at http://www.iss.net/security_center/advice/Exploits/Ports/default.htm is one typical list.

Sure, you get some scanners who go for the entire port range, but as that is far less effective, this list is going to be a pretty good indication of the most scanned ports.


How far can we go in preventing videos from spreading out using P2P networks like BitTorrent? Everyday, I see many of my friends downloading movies off P2P networks like BitTorrent. Isn't there any way for those hardworking movie producers to save their work from being distributed like this?

As a security enthusiast, I'm interested in knowing the technical methodologies for stopping the files from spreading over BitTorrents. I know securing 100% is not possible, but how far can we really go? Or, how difficult can we make it?

PS: I've heard that there are some security companies which protect movies from being spread over internet (I guess that includes torrents too?). I wonder how they do it?

One tool for trying to enforce DRM is watermarking, i.e. embedding within the media itself a mark which is (almost) invisible to the human viewer, but which is resilient to copies (i.e. the copy has it). Once media copies are individually marked with the identity of their rightful owner, you can trace the origin of fraudulent copies. Do not get it wrong: it is not the watermarking which prevents copying, it is the threat of the lawyer commandos you will send to smite the guy who was at the origin of the leakage.

Watermarking is a hard problem, notably because it must rely on embedding information which is not visible, i.e. exactly the kind of thing that compression algorithms remove. Moreover, even with a digital-only media, there can be cropping or stretching or colour rebalancing or resampling or whatever, so watermarking must rely on properties which are not at the "pixel" level. The name is well chosen: watermarking is quite similar to the act of writing... on water.

Since the wannabe pirate has a vested interest in removing the watermark, this implies that the scheme must be "well hidden". There is a generic attack for that, which consists in degrading image quality until the mark has disappeared; by dichotomy, one can find the precise alteration which kills the mark, at which point it becomes easy to remove or modify the mark without visually altering the media. Therefore, the only kind of watermarking which really resists attacker is the one where the attacker has no way of testing whether the mark is there or not. So we are talking about professional investigators roaming the Torrents on your behalf, looking for the mark in shared files; and not about watermarking checks within graphics cards.

Another tool for enforcing DRM is targeted distribution: each copy of the media is encrypted with a key which is specific to a single reading device. There is a nifty tool called broadcast encryption which is what Blu-ray employs. Each single device able to read Blu-ray discs has its own secret encryption key; one can imagine a Blu-ray disc as containing:

the media, encrypted with a per-media key K;
encrypted copies of K by each device key Ki, for all existing devices in the world.

Then a media distributor may opt to not include the encryption of K with K678349 if it turns out that the owner of the device 678349 has "misbehaved". Moreover, all "normal" devices will insist of decrypting media, i.e. will reject unencrypted data. The niftiness of broadcast encryption is that is allows for doing that without having to embed billions of encrypted copies of K in each disc.

There again, the technical tool of broadcast encryption does not prevent copying; it merely allows for retaliation on wide scale illegal copying ventures, and ultimately may result in a "market split": namely, to ensure that, in order to view illegally copied contents, perpetrators must use a non-standard device such as a computer or a physically modified reader. There will be people who do that; but there will also be people who do not.

Remember that anti-piracy tools are economically justified, and economy is statistics: media distributors do not want to kill unauthorized copying per se, they just want to make more money. And they view an unauthorized copy as a loss, since the copier could have bought the genuine thing instead. Any tool which reduces the amount of copying can become a "big win" (a technical term meaning "millions of dollars").

The common point in all these tools is that they do not technically prevent data copying. Because it is not possible: if the user can see it, he can record it and then see it again. The tools are meant to support larger anti-copying process which do not happen in the computer world, but rather in the mundane real world where police forces may bash your door at 6:00 AM.

If we are to believe the major media distribution companies, anti-copying strategies like those explained above are totally inefficient and legislators MUST take immediate actions such as raising new taxes for their exclusive benefits. According to the same major media companies, anti-copying strategies are 100% effective and if you share a single movie on the Internet, they will get you and send you to Guantanamo within 48 hours. Whether in reality DRM works is anyone's guess.


Why would a goal of DLP solution implementation include "loss of mitigation"? I'm studying for the CCSP exam and a practice question read:

  The goals of DLP solution implementation include all of the following,
  except:

  A. Policy enforcement
  B. Elasticity
  C. Data discovery
  D. Loss of mitigation

I chose D because I don't see how a DLP solution could make mitigation worse...

According to the test prep book though, the answer is B because:

  DLP does not have anything to do with elasticity, which is the
  capability of the environment to scale up or down according to demand.
  All the rest are goals of DLP implementations.

OK, fair enough.  I clearly see how I was wrong on the elasticity point.  But why is D not a valid answer?  I reviewed the prep material again and don't see this explained.  Can someone please elaborate?

This was probably a typo. Data Loss mitigation is obviously a goal of DLP. Elasticity, as you said, is not a goal of DLP.


Who watches the watchmen? User empowerment over firewall behaviour on a personal computer I've been exploring the gamut of free Windows firewall applications recently and have encountered the following problem:

The better firewalls are excellent at stopping other apps from phoning home for user reporting, unsolicited patches and other suspect behaviour; but the firewall apps themselves can and often do whatever they please*.

So who watches the watchmen?

Or in more concrete terms: How do security experts resolve this problem?

(Two firewalls somehow competing for the same low-level network library?)

 * I won't name names here.

The built-in Windows firewall is now advanced enough that third-party firewalls typically don't have anything left that is useful and novel to bring to the table.

So security experts generally don't use third-party software-based firewalls. There's value in hardware firewalls, which offer a layer of protection against a compromised host, and there's a value in software firewalls, which offer a zero-cost baseline level of protection for all devices or a fall-back secondary layer of protection beyond just an external HW firewall. But really the one that comes with newer versions of Windows is more than sophisticated enough to fit that role. The additional security to be gained by installing a third-party alternative rounds to zero.

As for the general question of trust; that really is the kicker. I trust Microsoft to patch Windows because... I have to. Do I trust Adobe to update flash correctly? Oh, how about this: do I trust Oracle to ship spyware-free updates to Java? (Stupid Ask toolbar). But if I can't trust Oracle, then who can I trust to update Java. Or... do I just have to abandon Java altogether?

You don't so much watch the watchers so much as you pick the watchers when it comes to application security. Either you trust the vendor and install their software, including its updating and tracking behavior, what every that may be ... or you don't.


Why does Antivirus Softwares have an Issue with EXE Packers Im trying to pack an Executable using an Exe Packer like UPX.I packed and checked the File with VirusTotal.com.Here some 9 Antivirus Products say its a Virus actually its a harmless exe.I think the AV Engines which are based on Ikarus has problems like this.
Why can't they check the file properly using better techniques before flagging it as a virus.

Kaspersky and Nod32 have unpackers for them. Some other are just lazy to do so and instead they label it as a hack tool. You can try different packers that they don't detect or just rar your exe instead.


Automated encryption detection Is there any program that, given a cipher text, it would tell me what the encryption algorithm is?

What if I have the plain text? Is there something that can be done in that case?

No.

The whole point to encryption is to produce a cipher-text that is indistinguishable from random noise.

Absent any outside hints, the ONLY way to determine what encryption mechanism is used is to run the decryption routine with the correct password and check the result to see if it looks correct.

On a related note, likewise the only way to determine whether you're using the correct password is to run the decryption routine with the correct cipher and check the result.


Personal cipher/digest preferences ignored when generating a new key pair in GnuPG I have specified personal digest preferences in my ~/.gnupg/gpg.conf:

personal-digest-preferences SHA512 SHA256 SHA384 SHA224 SHA1

then, I have generated a new key pair. But when I check the preferred algorithms, I see they are at their defaults, instead of my specified preferences:

gpg -a --export "testuser@mydomain.com" | gpg --list-packets | grep 'pref-hash-*'
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)

8 2 9 10 11 corresponds to SHA256 SHA-1 SHA384 SHA512 SHA224

Why are my preferences being ignored?

How can I enforce them when generating a new key pair?

The personal-digest-preferences option does not set preferred digest algorithms for creating keys, but during signing (if also encrypting at the same time, the most preferred algorithm supported by the recipient is chosen). From man gpg:

   --personal-digest-preferences string
          Set  the list of personal digest preferences to string.  Use gpg --version to
          get a list of available algorithms, and use none to set no preference at all.
          This allows the user to safely override the algorithm chosen by the recipient
          key preferences, as GPG will only select an algorithm that is usable  by  all
          recipients.   The  most  highly  ranked digest algorithm in this list is also
          used when signing without encryption (e.g. --clearsign or --sign).

To set the default preferences for creating new keys, use default-preference list instead. Be aware this requires the same input you'd use for setpref in the --edit-key menu; containing all your preferences for encryption, digest and compression algorithms.

   --edit-key
          Present  a  menu  which  enables you to do most of the key management related
          tasks.  It expects the specification of a key on the command line.

          [...]

          setpref string
                 Set  the  list  of  user ID preferences to string for all (or just the
                 selected) user IDs. Calling setpref with no arguments sets the prefer‐
                 ence list to the default (either built-in or set via --default-prefer‐
                 ence-list), and calling setpref with "none" as the  argument  sets  an
                 empty  preference  list. [...]


Can I rely on openssl_random_pseudo_bytes() being very random in PHP? I came across an application which needs to generate a random token for each user. It is very important that each generated token is unique. Application code was as follows:

$token = md5(open_ssl_random_pseudo_bytes(64));

I don't know exactly how open_ssl_random_pseudo_bytes works or why the  number "64" was chosen, nor how those bytes play together with MD5 hashing.

So how random is this token really? If the code is ran 1 billion times, will the tokens be unique?

open_ssl_random_pseudo_bytes is a cryptographically secure pseudo random number generator (CSPRNG).

In layman's terms, this means that it can generate an unpredictable, uniformly distributed sequence, that is suitable for key generation. The unpredictable property is important, because even if the full state of the random number generator is known, an attacker cannot recreate previously generated sequences, and it is unfeasible for an external observer to guess the state in order to predict future sequences.

This is in contrast to say a random number generator that takes its seed from the number of seconds past midnight and then generates predictable sequences based on this seed. In this case an attacker can simply set their own system to generate numbers using the same seed and can effectively guess token values in order to use them for their own nefarious purposes.

64 bytes will give you 512 bits of entropy. Since MD5 outputs hashes of 128 bits, there is no advantage of having the entropy generated being greater than 128. If the code is ran one billion times then there is a statistically probable chance of it always being unique because you have an output keyspace of 2128 (3.4 * 1038). The collision rate of MD5 is about 264 which is about 18 billion billion.


Backend Authentication of Mobile App: Session ID vs. OAuth Currently I am developing an iOS/Android app and a corresponding backend in PHP. In the last days I read a lot about user authentication and now I am a bit confused.

For now I am using a session ID for user authentication. A user can login in the app using email and password. The credentials will be send to the server in a post request and then I will generate a session ID in PHP. The session ID is returned to the app and after that used for calling the API.

The session ID is currently only expiring if the user is logging out or if he changes his password.

I am now wondering if my solution is secure. I read a lot about OAuth but it seems to be hard to implement and I do not really understand the security benefit in my case (except that the keys are expiring).

So my question: Is my solution secure or should I somehow improve it? How secure is it compared to OAuth?

Oauth is an authorization system, not an authentication system.

OAuth is intended to provide secure access to a resource by a third party. For example, there are applications that allow you to schedule posts to various social media platforms, such as Facebook and Twitter.  These applications will store your posts then, at the scheduled time, make a post to that system on your behalf, without having your credentials.

Another common use is, if you are a third party, such as an information scraping tool that is set up to look like a "What color pocket lint matches your auras" poll, such apps will be given some identifying information about you, such as your name and user ID (and possibly a LOT more, if you don't check the permissions carefully.)  These provide a round-about identification system, that can sometimes stand in place of authorization, if you trust the OAuth provider.  That is, there is no way to prevent this OAuth provider from lying to you about the identification; an admin for the provider could claim to be one of your users and you would have no way to know for certain, if you use their OAuth service as authentication.

If you want to identify users of your mobile app, you could have a "Sign in with [social media platform]" option using OAuth.  This can decrease some of the friction of signing in, compared to using a username and password.  Just keep in mind that, in this case, you're not the one authenticating your users.

As far as authenticating a user with a normal username and password in your app, and having a session ID passed with each request; this is how most sites work.  The OWASP cheat sheet on session management goes into details, but the general best practice can be summed up as:

At least 128 bits (16 bytes, 22 printable Base64 characters) long.
Generated with a cryptographically secure PRNG.
Does not represent anything except the session ID (don't include the username).
Before authenticating, switch to TLS. Never use an authenticated session in non-TLS.
Cookies may not apply to you, unless you're using a browser, but if they do apply, must have the Secure, SameSite, and HttpOnly attributes with properly configured (and not too permissive) domain and path attributes.
Recycled on privilege level change (login, logout, changing password).
Idle timeouts and maximum timeouts.

Since you are writing a mobile app, you have some more assurances that many web developers don't have. You do not have to rely on cookies for storing your session IDs, so you can get away with having two tokens; a short term session token for your API access, perhaps valid for a few hours, and the other (a "refresh token") to request your short term tokens.  This refresh token should be much higher entropy than a session token. In any case, 256 bit tokens will protect against brute force attempts until the heat death of the universe.

You can also use this refresh token as a shared secret, rather than a simple ID like the session ID is. When negotiating a new session ID, you would send some random bytes to the client. They will append these bytes to their refresh token, and calculate a hash based on that, and send the result back.  You then compare what they sent back with what your server expects (after doing the same hashing of the refresh token and your nonce). This proves that the client has the correct refresh token, without sending the refresh token over the network.

With this system, an attacker who performed a successful Man-in-the-Middle attack can only hijack a session for as long as you haven't recycled your session IDs, and users will not need to re-authenticate constantly, for as long as the refresh tokens are valid.


What is the difference between CERT C secure coding standard and other coding standards? We are updating our C, C++ and C# coding standards to include security requirements. I know there are coding standards based on the following:

PCI-DSS
CWE Top 25
OWASP Top 10
NIST SAMATE

What is the difference bet these and the CERT C secure coding standard?

Thanks

CERT C is specific guiance on writing "secure and resilient software in C and C++". The focus is on language specific advice on what to do and what not to do with what is a very powerful language that assumes you know what you are doing.  Note that these languages are often used in writing low level code for infrastructure devices, or for embedded systems, so it is vital that they are well written.

PCI-DSS is specific to the payments industry and is a mixture of practice and policy statements that are not code specific. Worth reading if you store credit card information, or for general information on good security practice, but not directly related to you otherwise.

The CWE Top 25 is a list of the most common software mistakes made by people writing software regardless of language or purpose.

The OWASP Top 10 is the list of most common vulnerabilities in web based applications, which includes non-coded vulnerabilities.

NIST SAMATE is part of a software assurance framework. It details the processes and practices around ensuring that a software product does only what is intended, and is free from tampering.

So in short, DO use CERT C for your C and C++. And read and incorporate the Top x as appropriate to your software products.SAMATE is far bigger than your task at hand.

Last time I was starting out greenfields (2006) we used a book called "The Elements of C# Style" as our standards bible. We only used it to settle disputes where the team could not agree on an approach. I don't know if it reflects the latest version of C# though.


stronger encryption for SSH keys I configured my server to encrypt user passwords using 500,000 rounds of SHA-512.

The question is, how does the standard AES-128-CBC encrypted SSH private key stack up to that, provided the same (or similar length) password/passphrase is used? This must be a human-typeable passphrase, of course, and the lack of entropy in this is (hopefully) the weakest link here. My understanding is that key-strengthening will extend the effort required to brute-force the passphrase, no matter how weak the passphrase is.

It's clear to me that since the public key is public, and can be used to verify the private key, the security of that private key will depend on the passphrase (the length of the RSA key will not factor in to how easy it is to reveal it). I imagine that check would be quite fast, so I would ideally want to increase the number of rounds and use stronger cipher suites so that the process of bruteforcing the passphrase is slowed down.

How much extra security on the passphrase can be gained by using PKCS#8 for a SSH private key?

I'm also wondering about ways to potentially improve upon this. Is there a way to make this encryption

openssl pkcs8 -topk8 -v2 des3

use even more rounds than the default (and still be accepted by ssh)? Also, are there even stronger suites that can be used? I'm dealing with Centos 6.4 here for now (since I like kickstart scripts), so it's probably a good idea not to be messing with the secure program suite if I can help it, but maybe there exists an even stronger symmetric cipher suite than PKCS#8 that can be used?

One thing I noticed is that the PBKDF2 here doesn't seem to specify the underlying hash used. Looking at the list it doesn't get any better than SHA1 it seems.

I want to find a way to make the best use of the ~0.5 second tolerable for successful authentication to help maximize the amount of computation required for brute-forcing.

I guess if I really cared about strengthening I should be looking at scrypt, but there is no native support in the tools for it, so this can't be used for day-to-day SSH private key management (but it could be suitable for use in special applications).

Edit: Interesting. My encrypted private-key on CentOS looks like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,D3A046CD...

I suppose this isn't necessarily any worse than AES-128-CBC (which is what my Mac produced).

What happens for private key storage is a bit intricate because it involves several layers of underspecified crud accumulated over years and kept for backward compatibility. Let's unravel the mystery.

For its cryptographic operations, including private key storage (that which we are presently interested in), OpenSSH relies on the OpenSSL library. So OpenSSH will support what OpenSSL supports.

A private key is a bunch of mathematical objects which can be encoded in a structure which is, normally, binary (i.e. a bunch of bytes, not printable characters). Let's assume a RSA key. The format for a RSA private key is defined in PKCS#1 as an ASN.1 structure which will be encoded using the DER encoding rules.

Since a lot of crypto-related tools began their life in the early and mid-1990s and, at that time, email was most fashionable (the Web was still young), tools strived at using characters which could be pasted into an email (attached files were not yet common in these days). Notably, there was an early standard called Privacy-enhanced Electronic Mail, or "PEM". That standard was never really deployed or used, and other systems trumped it (namely PGP and S/MIME), but one feature of PEM stuck: a way to encode binary object into printable text. This is the PEM format. It looks like this:

-----BEGIN SOMETHING-----
Some-optional: headers

Base64+Encoded+Data==
-----END SOMETHING-----

So PEM is a kind of wrapper with the binary data being encoded in Base64, and header and footer lines added, which include a type (the "SOMETHING"). The "optional headers" is a later addition of OpenSSL, and it has never been standardized, so PEM-with-headers is documented only as "what OpenSSL does". OpenSSL documentation being what it is, this means that, in order to know what this process exactly entails, you have to dive in the dreaded OpenSSL source code.

Here is an unencrypted RSA private key, in PEM format:

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDQ33ndDr5N/AI8y2PzrqGbadLeS5fSf2GsVJx2B2KxhazL2z5O
ufin+wjJ1hW12/zWyQs/9CFYQFrife+PrMUOdLitsmlD3l4lBQ29+XKsmPabtINP
JQ0n4dxgBGeFxTCd4lJwiysmVsXPnNrgQTcx2nirrIk1C7wSW9Ai9W3fZQIDAQAB
AoGBAKiKSvkW9nRSzzNjIwn0da7EG0UIVj+iTZwSwhVzLC32oVH1XTeFVKGnLJZA
y0/tbP2bSBqY0Xc2pp9v4yhZzr6/BUPX+N1FOW8Q5OXHMD4fXSixrX0vYOT8hQuC
ehTAXsStjkZqzCdCsKV9YIduTHoyjL2jG6QBvFQK7kHaYUwZAkEA+rp2b+eBDJrg
lqcPOE2HkCkQcReSW0OIoUgd2tIiPFL8HSNwKvvAAH+QBKL6jvecLswJneecon8Z
jsgn4K/EpwJBANVDultbYq/h3F5FbAQ4r6cMQ2ZmmhMFdt8rRvAdEz18CuobGvAQ
y31hU/InW0n+Z0oHCsIgyowSeCGwRLMJYRMCQGKDXQG+/k+Lku7emPZQUBFucQ1e
a5z8PfTQtxpBMj5thK2WPP5GiDwp4tZPiw8dbvpcJPMsC7k1Iz+cmT6JEUUCQBxz
X54mb+D06bgt3L4nbc+ERE2Z7H4TIYueM2V/C30NWktm+E4Ef5EnddJ9S6Fwbgkj
LV0+kKblI9+iq1eTLb8CQQC+QDF7Y1o4IpDGcu+3WhS/pI/CkXD2pDMJM6rGBgG6
g9D1VTPCx0LZAWK4GdmELhPM+0ePH4P24/VsJY4mvutQ
-----END RSA PRIVATE KEY-----

As you can see, the type is "RSA PRIVATE KEY". The ASN.1 structure can be explored with openssl asn1parse:

$ openssl asn1parse -i -in keyraw.pem
    0:d=0  hl=4 l= 605 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=3 l= 129 prim:  INTEGER           :D0DF79DD0EBE4DFC023CCB63F3AEA19B69D2DE4B97D27F61AC549C760762B185ACCBDB3E4EB9F8A7FB08C9D615B5DBFCD6C90B3FF42158405AE27DEF8FACC50E74B8ADB26943DE5E25050DBDF972AC98F69BB4834F250D27E1DC60046785C5309DE252708B2B2656C5CF9CDAE0413731DA78ABAC89350BBC125BD022F56DDF65
  139:d=1  hl=2 l=   3 prim:  INTEGER           :010001
  144:d=1  hl=3 l= 129 prim:  INTEGER           :A88A4AF916F67452CF33632309F475AEC41B4508563FA24D9C12C215732C2DF6A151F55D378554A1A72C9640CB4FED6CFD9B481A98D17736A69F6FE32859CEBEBF0543D7F8DD45396F10E4E5C7303E1F5D28B1AD7D2F60E4FC850B827A14C05EC4AD8E466ACC2742B0A57D60876E4C7A328CBDA31BA401BC540AEE41DA614C19
  276:d=1  hl=2 l=  65 prim:  INTEGER           :FABA766FE7810C9AE096A70F384D879029107117925B4388A1481DDAD2223C52FC1D23702AFBC0007F9004A2FA8EF79C2ECC099DE79CA27F198EC827E0AFC4A7
  343:d=1  hl=2 l=  65 prim:  INTEGER           :D543BA5B5B62AFE1DC5E456C0438AFA70C4366669A130576DF2B46F01D133D7C0AEA1B1AF010CB7D6153F2275B49FE674A070AC220CA8C127821B044B3096113
  410:d=1  hl=2 l=  64 prim:  INTEGER           :62835D01BEFE4F8B92EEDE98F65050116E710D5E6B9CFC3DF4D0B71A41323E6D84AD963CFE46883C29E2D64F8B0F1D6EFA5C24F32C0BB935233F9C993E891145
  476:d=1  hl=2 l=  64 prim:  INTEGER           :1C735F9E266FE0F4E9B82DDCBE276DCF84444D99EC7E13218B9E33657F0B7D0D5A4B66F84E047F912775D27D4BA1706E09232D5D3E90A6E523DFA2AB57932DBF
  542:d=1  hl=2 l=  65 prim:  INTEGER           :BE40317B635A382290C672EFB75A14BFA48FC29170F6A4330933AAC60601BA83D0F55533C2C742D90162B819D9842E13CCFB478F1F83F6E3F56C258E26BEEB50

We recognize here the components of a RSA private key: some big integers. See PKCS#1 for mathematical details.

It so happens that the PEM-extended format that OpenSSL uses supports password-based encryption. After some code reading, it turns out that encryption uses CBC mode, with an IV and algorithm specified in the headers; and the password-to-key transform relies on EVP_BytesToKey() (defined in crypto\evp\evp_key.c) with the following features:

This is a non-standard hash-based key derivation function.
The IV for encryption is also used as salt.
The hash function is MD5.
The hash is used repeatedly, for n iterations, but in the case of PEM encryption, the iteration count n is set to 1.

That the KDF is non-standard is a source of worry. Reusing the encryption IV for a salt is a minor worry (that's mathematically unclean, but probably not a real problem -- and, at least, there is a salt). Use of MD5 is also a minor worry (though MD5 is thoroughly broken with regards to collisions, key derivation usually relies on preimage resistance, for which MD5 is still quite strong, almost as good as new). The iteration count set to 1 (which means, no loop at all) is a serious issue.

This means that if an attacker tries to guess the password for a PEM-encrypted key, the computational cost for each try will be minimal. With a good GPU, that attacker could try several billions of passwords per second. That's way too fast for comfort. Password-based key derivation should be both salted and slow, and the OpenSSL PEM-encryption format fails on the second point. See this answer for a detailed discussion.

Here is a PEM-encrypted private key; encryption algorithm was set to AES-128. The password is "1234":

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,8680A1BEAE5661AAD8DA344B7495BCD4

4cvmuk8onrB5IQVRr6xRUBt6yRcjNUGcUWq0CcyX4p4iijANv/S7H5Ga8e5e+12m
k6UUt65mF54Ddh+WE4lHHy5yYEPa25tr/KBMErEhHJxYFiwRwgw/KoF2V8Cpgidd
BA5aeO+5/FmCiTkx/tGYbpE2emfcQ+oNdAKRhIEjIAfItrU4Bj2nQZdiiY0tFEfT
hn5HZ0X1i1yi63nxVGQH+oQQH9+ccPk87cIRLf3IK1B3M0J0j11XDhQdIXwAx9hV
52GXgkk0NX7EtT5Cq3x0Q513e70QA9ua1lt8yaCynkLrYKmMQQCKsLlJDSh+sUyu
ndiVl0g73cUPd962Tp/WCLOV4/DWShfZexfjoibjCkR81OVa9cguYITCXV3QGRCM
wo09DI/INOs1s6FS4ZKugpwgKEX6knh0Fo1i6DdVJQfeQvUo+MhbFjjK0SXT4QWc
4rlQv0Q1YoNn1EzFzsVwx7PhtU9wo4PU1978+582mrJBjteIN9a8z+7lZT1qKynD
BG3XUjnWAq4k5KUj5mEJkSSs2R2AIhHNiSmwmcuzHf67er1KrWvL+g8AXXJ8xLjh
P6ImJeMoEI7P2zb4FvSkQFF5SDjmaPNPpo6xe330EdSSWZTZtcgc9yH++I8ZX9Kb
0UnWic5HTZOx0VLqEqDw+iWufnUDMvq98tGD5c+BQqqofBZae5YNYfko1tCGoz/3
ZygMcOdRqRugur5SiCZnYCnIeQvVNi7nwfp2Bb3K0XMCr12IdeRDuoe45MzoG9zD
hLk0Y3VHS3eANvEsBMAwcyTBjgs8Q3bHdHwnPjVcAo3auOkyXUHZ7DEIxnmvVfaS
-----END RSA PRIVATE KEY-----

Because of the encryption, the bytes can no longer be analysed with asn1parse.

PKCS#8 is an unrelated standard for encoding private keys. It is actually a wrapper. A PKCS#8 object is an ASN.1 structure which includes some type information and, as a sub-object, a private key. The type information will state "this is a RSA private key". Since PKCS#8 is ASN.1-based, it results in non-printable binary, so OpenSSL will happily wrap it again in a PEM object.

Thus, here is the same RSA private key as above, as a PKCS#8 object, itself PEM-encoded:

-----BEGIN PRIVATE KEY-----
MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBANDfed0Ovk38AjzL
Y/OuoZtp0t5Ll9J/YaxUnHYHYrGFrMvbPk65+Kf7CMnWFbXb/NbJCz/0IVhAWuJ9
74+sxQ50uK2yaUPeXiUFDb35cqyY9pu0g08lDSfh3GAEZ4XFMJ3iUnCLKyZWxc+c
2uBBNzHaeKusiTULvBJb0CL1bd9lAgMBAAECgYEAqIpK+Rb2dFLPM2MjCfR1rsQb
RQhWP6JNnBLCFXMsLfahUfVdN4VUoacslkDLT+1s/ZtIGpjRdzamn2/jKFnOvr8F
Q9f43UU5bxDk5ccwPh9dKLGtfS9g5PyFC4J6FMBexK2ORmrMJ0KwpX1gh25MejKM
vaMbpAG8VAruQdphTBkCQQD6unZv54EMmuCWpw84TYeQKRBxF5JbQ4ihSB3a0iI8
UvwdI3Aq+8AAf5AEovqO95wuzAmd55yifxmOyCfgr8SnAkEA1UO6W1tir+HcXkVs
BDivpwxDZmaaEwV23ytG8B0TPXwK6hsa8BDLfWFT8idbSf5nSgcKwiDKjBJ4IbBE
swlhEwJAYoNdAb7+T4uS7t6Y9lBQEW5xDV5rnPw99NC3GkEyPm2ErZY8/kaIPCni
1k+LDx1u+lwk8ywLuTUjP5yZPokRRQJAHHNfniZv4PTpuC3cvidtz4RETZnsfhMh
i54zZX8LfQ1aS2b4TgR/kSd10n1LoXBuCSMtXT6QpuUj36KrV5MtvwJBAL5AMXtj
WjgikMZy77daFL+kj8KRcPakMwkzqsYGAbqD0PVVM8LHQtkBYrgZ2YQuE8z7R48f
g/bj9Wwljia+61A=
-----END PRIVATE KEY-----

As you see, the type indicated in the PEM header is no longer "RSA PRIVATE KEY" but just "PRIVATE KEY". If we apply asn1parse on it, we get this:

    0:d=0  hl=4 l= 631 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=2 l=  13 cons:  SEQUENCE
    9:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   20:d=2  hl=2 l=   0 prim:   NULL
   22:d=1  hl=4 l= 609 prim:  OCTET STRING      [HEX DUMP]:30820<skip...>

(I have cut a lot of bytes in the last line). We see that the structure begins by an identifier which says "this is a RSA private key", and the private key itself is included as an OCTET STRING (and the contents of that string are exactly the ASN.1-based structure described above).

PKCS#8 optionally supports password-based encryption. This is a very open format so it is potentially compatible with every password-based encryption system in the world, but software has to support it. OpenSSL supports old DES+MD5 encryption, or the newer PBKDF2 and a configurable algorithm. DES (not 3DES) is a minor issue: DES is relatively weak because of its small key size (56 bits) making a break through exhaustive search technologically feasible (it has been done); however, this would be quite expensive for an amateur. Still, it is better to use PBKDF2 and a better encryption algorithm.

Given a raw private key as shown above, here is an OpenSSL command-line which turns it into a PKCS#8 object, with 3DES encryption and PBKDF2 for the password-based key derivation:

openssl pkcs8 -topk8 -in keyraw.pem -out keypk8.pem -v2 des3

which yields:

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIZT3rvVU85p0CAggA
MBQGCCqGSIb3DQMHBAgtYXWrNG+OYgSCAoCewt8WkgCDaBCSOoe88WTpV2haxUFW
iWkdJQtEkzkpYnwA0E0Bj5CBnSd3EdSRmup0rP9WxzdMe+qx2N+GGLTcmA7pMyBV
XK9OTdiixMWvlG64lrLFtQxoKaxo48zUVobLuRrtaVLvwZ7OpO4hA2zsl6qaWaV7
8GEiAWz28K3DIBDVr1CKpEdFf7epkC7e1/ojJDNAwPiE9rxkaqGHpogqJQKb5s8X
ZyGhVG3rPuwgOxhU5d1G7K6+N9wKYkZXiCmsoqZxD94M3QH8sM8YF41rxBsbPSJ/
7JgGQMOJQxxrdeHSAt5P1iasI7lNXa7HacTZl1nPDXpnpjKA5E/jNMf1EgV+sN3f
pL4GoFvw8zImOF4OHdo9KBz61oKFylQrGQM6WhCsTqsSVZxR0tH8ERSOhhWn2wmy
NgiagfVT4nED9XFInEwTKoXKUjTSOHUmbTl/HF637NrYjSBLgT/e+XBQBmFMSaNc
+KLlJRHpjB8QZ8cIdDFwVIYkmm4Po7h1uYob1d2/4saxjHrtZ8f7GqmT/SGXMpj5
eL0bXDXdjcapDkLx5X0/BYI3AYTlFXEZU0UJT8aad0Fiygw1bLVDR8yDl63Bthlb
gS15LhjqGYGhgX3tARS94HtBvlSAtgV6AB5QjEJfU7jgyu0lFn1hTULmwFJVkjj6
Oy2WeuHseOZ1X45V7DvNcS1iT7fttwQZoSvdks8WulsodpOr7sbtaJbsUUToTxIN
GtNQo9Ce/QAeONmSf8G9jbBURBmLH+kzzzptYcCsVaaUnWPpgebH/WJRa83quPw6
fwy3xZgg9pPHFBiFAG2c3Uuelat/eXhXdW74XlDgOIpmbMfsDxaVOiuM
-----END ENCRYPTED PRIVATE KEY-----

So now that's an "ENCRYPTED PRIVATE KEY". Let's see what asn1parse can say about it:

    0:d=0  hl=4 l= 710 cons: SEQUENCE
    4:d=1  hl=2 l=  64 cons:  SEQUENCE
    6:d=2  hl=2 l=   9 prim:   OBJECT            :PBES2
   17:d=2  hl=2 l=  51 cons:   SEQUENCE
   19:d=3  hl=2 l=  27 cons:    SEQUENCE
   21:d=4  hl=2 l=   9 prim:     OBJECT            :PBKDF2
   32:d=4  hl=2 l=  14 cons:     SEQUENCE
   34:d=5  hl=2 l=   8 prim:      OCTET STRING      [HEX DUMP]:653DEBBD553CE69D
   44:d=5  hl=2 l=   2 prim:      INTEGER           :0800
   48:d=3  hl=2 l=  20 cons:    SEQUENCE
   50:d=4  hl=2 l=   8 prim:     OBJECT            :des-ede3-cbc
   60:d=4  hl=2 l=   8 prim:     OCTET STRING      [HEX DUMP]:2D6175AB346F8E62
   70:d=1  hl=4 l= 640 prim:  OCTET STRING      [HEX DUMP]:9EC2DF16920<skip...>

We see there that PBKDF2 is used. The OCTET STRING with contents 653DEBBD553CE69D is the salt for PBKDF2. The INTEGER of value 0800 (that's hexadecimal for 2048) is the iteration count. Encryption itself uses 3DES in CBC mode, with its own randomly generated IV (2D6175AB346F8E62). That's fine. PBKDF2 uses SHA-1 by default, which is not an issue.

It so happens that while OpenSSL supports somewhat arbitrary iteration counts (well, keep it under 2 billions to avoid issues with 32-bit signed integers), the openssl pkcs8 command-line tool does not allow you to change the iteration count from the default 2048, except to set it to 1 (with the -noiter option). So that's 2048 or 1, nothing else. 2048 is much better than 1 (say, it is 2048 times better), but it still is quite low by today's standard.

Summary: OpenSSH can accept private keys in raw RSA/PEM format, RSA/PEM with encryption, PKCS#8 with no encryption, or PKCS#8 with encryption (which can be "old-style" or PBKDF2). For password protection of the private key, against attackers who could steal a copy of your private key file, you really want to use the last option: PKCS#8 with encryption with PBKDF2. Unfortunately, with the openssl command-line tool, you cannot configure PBKDF2 much; you cannot choose the hash function (that's SHA-1, and that's it -- and that's not a real problem), and, more importantly, you cannot choose the iteration count, with a default of 2048 which is a bit low for comfort.

You could encrypt your key with some other tool, with a higher PBKDF2 iteration count, but I don't know of any readily available tool for that. This would be a matter of some programming with a crypto library.

In any case, you'd better have a strong password. 15 random lowercase letters (easy to type, not that hard to remember) will offer 70 bits of entropy, which is quite enough to thwart attackers, even when bad password derivation is used (iteration count of 1).


OpenSSH: Meaning of cipher with email address @openssh.com When using OpenSSH server (sshd) we specify allowed ciphers, host key algorithms and MACs. Some of those ciphers have an email address appended, for example aes256-gcm@openssh.com as opposed to aes256-ctr. What is the meaning of that? I checked sshd_config and couldn't find an explanation.

Those are algorithms defined by vendors like openssh, not defined by the SSH standard (IETF RFCs). They are extensions to the protocol. Of course, you are not guaranteed that software other than openssh would interoperate with those options.

The specifics of aes256-gcm@openssh.com is defined in openssh documentation:

  1.6 transport: AES-GCM

  OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
  Because of problems with the specification of the key exchange the
  behaviour of OpenSSH differs from the RFC as follows:

  AES-GCM is only negotiated as the cipher algorithms
  "aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as an
  MAC algorithm. Additionally, if AES-GCM is selected as the cipher the
  exchanged MAC algorithms are ignored and there doesn't have to be a
  matching MAC.

In this case, the non standard extension is used as a bugfix for the spec.

In general, using non standard extensions is how they are able to experimentally support a post quantum key exchange algorithm, sntrup4591761x25519-sha512@tinyssh.org, years before PQ Crypto will get standardized.

Compare this with how old Chrome used custom TLS cipher suite for ChaCha20Poly1305, before that was standardized by IETF in an incompatible way, and some TLS servers support old chacha and ietf-chacha. Or how Chrome did a series of post quantum crypto experiments using non-standard cipher suite values.

Algorithms that have been widely deployed and have not encountered problems might get "blessed" by IETF, and become standardized, and this, in theory, is how IETF protocols evolve: broad consensus among practitioners, rather than standardizing a design no one has tried to use (or even implemented at all) and discovering problems only after the standard is out.


PHP - Needing help to encrypt/hash a password for small application I have created a small script for work. It's an internal web script but has to be hosted on our public domain so I have created a very small PHP based login system using a login form and a session check. Instead of having to define the password in plain text, can someone show me how to add the password in an encrypted format, without the use of a database or external file?

My login code is posted at the bottom - just above it is the line that I would like to change this password to some kind of encryption so that it cannot be read plaintext should someone gain access to the files, or PHP screws up and starts printing in plain text. I have tried googling and searching SE bu everything is relating to DBs and external conf files.

$logins = array('username' => 'password123');

    <?php session_start();

if(isset($_POST['Submit'])){
$logins = array('username' => 'password123');

$Username = isset($_POST['Username']) ? $_POST['Username'] : '';
$Password = isset($_POST['Password']) ? $_POST['Password'] : '';

if (isset($logins[$Username]) && $logins[$Username] == $Password){

$_SESSION['UserData']['Username']=$logins[$Username];
  if (isset($_SESSION["login_redirect"])) {
        header("Location: " . $_SESSION["login_redirect"]);
        unset($_SESSION["login_redirect"]);
    } else {
        header("Location: index.php");
    }
exit;
} else {

/* Login failed display message */
$msg="Invalid Login Details";
}
}

Thanks for any and all help!

p.s. The script is hosted/served from HTTPS and HTTP2 on PHP 7x and apache in case it makes any difference.

Edit:

To start with there is only 1 user and password. there may be additional users in the future. But as it stands now just one is needed for the staff. There is no requirement for logging user actions etc at the moment.

The script will be on a subdomain of a public website which has its own WAF that also protects the sub dir, so things like brute force will be picked up. We also have Mod Security and CSF on the server which will also help out.

The script is being hosted on the public side as the company does not utilize an internal intranet, VPN or LDAP / AD server etc. The script needs to also be accessible outside the office - should the boss decide to work from home or Starbucks...

I only want to secure the password part because it is stored in plaintext inside the login.php file. If someone was to access it on the server or via FTP etc, they would have easy access to the password. And as mentioned should PHP break I do not want to password shown as plaintext on screen either.

So to update my question a little. Can someone give me starting pointers for replacing the password with a hashed password system instead?

Again I understand a number of people on here will suggest using corporate intranets, VPNs, dedicated platforms blah blah, please understand this is a small company and an even smaller project. Things like staff leaking passwords are less of a worry. I am more interested in securing the password that is already in place and keeping the script as small and as light as possible.

A few points:

Passwords should be hashed, not encrypted. Encryption is reversible; somebody who shouldn't have access but can see the app's source code can find the encrypted password and its encryption key, decrypt the password, and thereby gain access. Hashes are one-way; you can't turn a hash digest back into the text that was hashed.

You'll ideally want a slow hash function (PBKDF2, bcrypt, scrypt, or argon2, in order of increasing security) because fast hashes can be brute-forced pretty easily with modern hardware.
You'll definitely want to use a salted hash (the algorithms above will expect or auto-generate a salt), as otherwise an attacker can use a rainbow table (or simply Google the hash digest) to find the password very quickly.

The system you describe is far too fragile. With every user of this system sharing one password, it will get leaked. Somebody will leave the company, or sign in from a compromised system, or leave it on a sticky note where they shouldn't, or send it over an insecure communication channel, or something. In other words, there's no very secure way to do what you're asking. You really should have per-user access control, and yes, that probably means a database.

You also lose meaningful logging ability when you don't differentiate between users. If somebody gets in and abuses the system, you can't know who did it because all logins look the same. Of course, in the snippet above, you don't have any logging at all...

You don't mention any kind of password brute-forcing protection, without which an external attacker can probably crack the password in, at worst, a few days of attempts.

There are correct ways to handle your scenario, but they all work differently than you're describing.

Restrict the internal site to intranet (corporate network) IP addresses, and require external users to be on a VPN.
Delegate authentication to your internal login authority. If you have an LDAP/Active Directory server, you can pass the authentication request through to it. In fact, if you use Active Directory and IIS (probably not, since PHP, but still), this is as simple as setting the app to require "Windows Authentication".
Delegate authentication to an external provider, if you use one. For example, if your company uses Google Suite, you can use Google SSO (Single Sign-On) and verify that the user has a company email address. You could also use an external authentication provider, such as Auth0.
I guarantee that it doesn't need to be hosted on your public domain, although without knowing why you think so I can't offer better approaches. Still, this scenario is exactly what intranet servers exist for, and they can talk to your public web server over back-end channels (or via CORS through the client) if needed.

More generally, the fact that you're asking this indicates that you probably shouldn't be trying to roll your own authentication system. Without knowing more about the scenario, I can't say exactly what the risks are, but I would be very surprised if you manage to account for them all with a system like this one. Security is hard; it's a much better idea to go with a proven system developed by people who know what they're doing.


Changing picture as characters entered into password When Lotus Notes asks for the password, it displays a screen with a picture that appears to change after a new character is entered after the fifth character.

I have noticed the sequence of pictures is the same between closing and reopening Lotus Notes. Is this to distract an attacker from looking at the keyboard as someone types? Has this ever been proven effective? Also as far as I can tell a random amount of x's are added after each character is typed in. I guess this is so an attacker can't see the password length, but is there a point to having anything at all because the user doesn't know how many characters are typed?

EDIT: for what it's worth I didn't even realize the pictures were the same each time I typed in a password.

There is some information on this defunct page. Apparently, the idea that the "moving picture" is there to distract shoulder surfers is widespread, and wrong. That's not how this picture works; what it does is actually worse, although it proceeds from good intentions.

When you type the password letters, Lotus employs a "fairly complicated" but deterministic algorithm to map the password as entered to a picture; this basically is a hash function with a very small output size (the output is a "value" in the set of possible pictures). It is possible that the said hash function includes some server-specific secret, but it won't matter much. The real point is that, as you observe, when you enter your password you always end up with the same picture for a given password. The good intention is to achieve the two following properties:

Give an early visual warning as to whether the password was entered correctly or not; the user will soon learn the sequence of pictures for his own password, and thus if a picture changes, then the user knows that he typed the wrong key at that point (or possible a few characters before).
An attacker who tries to mimic this login popup and make the user type his password in a fake popup would supposedly find it "difficult" to recompute the pictures and display them correctly.

The second reason is pure baloney, when you think about it: the "complicated algorithm" cannot be kept secret (especially if the fake popup is actually a man-in-the-middle attack and the true popup is used under the covers to get the actual pictures), and making pictures which move on the screen is really easy: that's what 99.9% of the Web is about.

The first reason, however, includes the seeds of destruction: this leaks information on the password. The pictures are on the screen and very visible; quite prominent, even. The "shoulder surfer" can see them from afar. And he can use them to prune out potential passwords. Indeed, if there are four possible pictures, then this leaks 2 bits per character: for an 8-character password, which would have, realistically, about 30 bits of entropy, this is then reduced to a meagre 14 bits.

Indeed, this feature is analogous to a system which would write on the screen, in big letters, and for each password character: "this character is a digit" / "this character is an uppercase letter between A and M" / ...

Therefore, this "picture" system is downright dangerous and should be banned.

As for the password length, the number of characters is very easy to get for the attacker, because each key stroke is highly audible. The shoulder surfer just needs to be within earshot of the victim, and could easily record the sequence with his smartphone to listen it later on, suitable slowed down, and thus obtain the password length. Under these conditions, hiding the length from the user himself is pointless.


Is there a way to encrypt an existing ext4 filesystem with already data on it? I have a big drive with already data on it, that I would like to encrypt (ext4).

Is there a way to encrypt that disk without having to move the data to another drive first?

Or maybe, this would be the better solution, once that question is solved:

How do I create an auto-growing encrypted folder on linux?

You can use Truecrypt, it allows you to encrypt a drive in place, although this takes longer than moving the data and rewrite it encrypted.

This explains quite well how to do it. (edit: that is for Windows though, not entirely sure if it looks the same for every OS)

edit: nvm, Linux TrueCrypt supports fixed size only


Why did browsers choose to implement HSTS with Preload over checking custom DNS information? Browsers and standards bodies favor HSTS with Preload because it avoids ever sending an http request to a website that supports https. This is good, because cleartext http requests can be intercepted to set up Man in The Middle attacks.

But a number of websites explain that a centralized Preload list doesn't scale up well to the mostly https web that has been proposed by W3C, the EFF, and others. Managing one centralized list creates a bottleneck for looking up, adding, and deleting list items.

Yet this technology has been implemented rather than, say, to use DNS, which is already nicely distributed and is already used by browsers to lookup URL domain names.

Of course, the DNS is not yet secure, and proposals to make it secure are controversial. But why would the DNS have to be secure to hold one more bit of information (whether the domain can support https--and ONLY https--or not)?

In the worst case, a malicious MiTM attack could make it seem that a website is insecure when it is actually secure. But in this case, an insecure connection would simply fail. This failure would deny the malicious user any advantage.

So naturally I'm wondering why a centralized HSTS with Preload is preferred over adding a new flag to DNS zones for indicating that the domain supports https connections.

But why would the DNS have to be secure to hold one more bit of information (whether the domain can support https--and ONLY https--or not)?

A man-in-the-middle attack could modify the DNS responses to remove the bit saying that a site requires HTTPS.

  In the worst case, a malicious MiTM attack could make it seem that a website is insecure when it is actually secure. But in this case, an insecure connection would simply fail. This failure would deny the malicious user any advantage.

A man-in-the-middle attack could make the insecure requests work.

Say paypal.com requires HTTPS connections (and doesn't respond to HTTP connections, or responds only with a redirect to https://paypal.com), and has the HTTPS-only DNS flag set. If a user is MITM-attacked, then the MITM can strip the HTTPS-only DNS flag from the DNS response for paypal.com, and then when the user makes an insecure HTTP connection to paypal.com, the MITM can proxy that connection to https://paypal.com and see all the requests and responses in plaintext. The user will believe they're talking with paypal.com over HTTP, and paypal.com will believe they're talking to the user over HTTPS.


Unauthorized API Access Without Key Header In order to test the security of my API, I want to act as sort of an attacker in order to try and gain access to my own API without an API key.

In order for me to send requests to this endpoint, I need to include a 32 long character string (API key/cert) in the header of the request. This means I basically can't brute force an API key, it would take ages.

What other options are out there for me to exploit and gain access to this endpoint? Is my API secure against a possible attack?

The information I know as an "attacker" is that the server the API runs on is Microsoft-IIS/8.5, running ASP.NET version 4.0.30319, and that this is a REST API.

There is not much known about your actual setup. But apart from trying to guess the key (i.e. brute forcing) the attacker might also

Try to sniff the key on the wire
Proper use of HTTPS will protect against this unless the attacker can make the client accept its own certificate and thus be a man in the middle.
Extract the key from the client side
Nothing is known about the client application. But a mobile application using the key might be reverse engineered, in a web application the attacker might use developer console to see the actual traffic in plain, XSS  issues in the client application might allow the attacker to extract the key from the client ...
Hack the server side and extract the key
For example using an SQL injection if the key is stored in a database etc
And maybe through other ways
For example because the developer inadvertently leaks the key when publishing the source code etc

  Is my API secure against a possible attack?

Your title asks about unauthorized access while this part asks about "secure against attacks" in general. Securing the key is not the only thing for securing an API. You should never assume that only a client fully controlled by you can use the API. This means you should also have proper input validation of what the client sends and not rely on the client to send only valid input. Additionally to this there are other attacks like DoS and maybe more. Again, too few is known about your actual setup in order to evaluate the security in more detail.

In summary: if you rely solely on the secrecy of the key your API is likely not secure against attacks.


Is it a bad idea to use port forwarding as a long-term access strategy? We are deploying multiple copies of the same system (some devices behind a gateway with NAT), and we need to have continued access for some of those devices. Right now our strategy is to have a set of non-standard ports that are configured to route to specific IP addresses behind the NAT. This setup is essentially replicated for every copy of the system.

Are there any security risks associated with that? Are there any better solutions available to do this?

Most people consider NAT 'security though obscurity' and is a bad idea. Nat should be used to preserve limited IP address space not as security, a good port scanner will find your servers. Most people use NAT AND a firewall, now they can be in the same box. As was indicated above if you want to talk to a business partner you want to use VPN.


USB Mouse in the meeting room In our meeting rooms we have at our disposal the necessary material for presentations. HDMI, and  mouse etc., lock down to the table (3 digit lock).

All the mouse have been removed for security reason, in fear of a modified mouse with keylogger, cryptovirus or other malware.

Without the consideration of social engeneering to enter the meeting rooms, is an USB mouse a real risk and vector?

Context:
One of the mouse have been replace by an other brand mouse. But it's definitivly not a mouse brought by the company. No mouse of that brand no computer of that brand were ever brought. The mouse have been inspected and look like it was not modify visible component are the same with the same mouse brought for comparaison. A real keylogger here will in capture a ton of domain password.

These are just some of the possible USB attack vectors: 29 Different types of USB attacks.

A mouse alone is unlikely to be an attack vector. A mouse logger is redundant with screen capture. However, as @domen hinted in the comment, there's really nothing special about the mouse-shaped device that will force the device to be recognised as a mouse. A mouse shaped device can identify itself as anything, including as a daisy chained device for which one of the connected device is a mouse, but also provides another, more malicious service.

With that said, hardware based attacks like USB attacks, while not unheard of, are fairly uncommon. In practice, there just aren't that many known instances of such attacks, unless you work for the NSA or a company with known regular history of corporate espionage, the chances to most people of being targeted by these kind of attacks are fairly slim.


DNS sending queries to weird IP I have noticed some strange activity on a dns server of mine and wanted to pick some brains. Every request being made to this dns server has an additional udp packet being sent to an ec2 IP address in Ireland. FYI, I am in the US so this should not be going to the Ireland at all. The udp packet sent each time contains each request being made on my dns server.

This is an internal dns server, running dnsmasq, and using OpenDNS for its lookups. Below are a couple of shots for some additional info. So I do not believe this address ec2 address should be appearing but I could be wrong. That is why I want to ask everyone here. Any info, tips, advice on this?

The IP address is for data.logentries.com:

$ dig data.logentries.com|grep 78.79
data.logentries.com.    98  IN  A   46.137.78.79

logentries.com provides log management and analytics and it appears someone at your site has signed up to it.