Is it common to allow local desktop and/or active directory admin access and rights for developers in organizations? I work at a company with a staff of about 1000+. We currently have programming development staff that work on web based projects (approx 50 people).

Recently due to security concerns our IT and Security department implemented a restriction no longer allowing local admin access on machines . The entire company runs Windows OS for both workstations and servers. I completely agreed with the decision to remove admin, honestly I thought it was long overdue (as the company deals with patient data and requires HIPAA compliance). Unfortunately I believe they took the decision too far. I assumed a subgroup or AD group would be created for users that legitimately needed admin access to do their job (EX my programming team) something like a Tech group that would retain admin access. However this was not the case, the only group created a specific Admin group for Network and Help Desk staff.

The main problem is, as web developers we run programs that require local admin access and unfortunately can't do our job without them running as admin. Example programs include Visual Studio for ASP.NET web development, MAMP for local development, composer, etc. I believe the main reason these programs need admin access is because they need to run and modify local IIS, command line, etc.

Basically there was short notice of when the local admin access was removed. After about 2 days of the development team being dead in the water in terms of being able to work and me and other team leaders basically yelling and screaming at the IT staff to come up with a solution they finally conceded and found a third party program that works as a pass through allowing the administrators to create the ability for certain programs to run as admin even though we don't have local admin access.

Unfortunately, this program we use for local admin access is incredibly buggy and unreliable and not from a reputable source and there doesn't seem to be much for alternatives out there. (I would prefer not to disclose the program we use.)

My question is, is it typical to not allow Programmers/Developers local admin access at a company or corporation? And if it is common practice to do so, then how do developers run the programs they need as local admin?

A little more information on our network environment (not that it really relates to the question I just thought I'd add this):

We use AppBlocker to block programs not on an approved list
We use an email security blocker that does things like scan and convert attachments to PDF, etc.
We have at least 2 major antivirus programs on all workstations.
The network and it's servers very segregated, users only have access to certain servers, folders, and databases that they legitimately need access to.

Here's one data point from a software company that has an interest in security. I know this is common in similar organisations.

There is a number of networks. They are physically separated and airgapped, run different colour-coded network cables.

Each employee has an 'administration' machine, which can connect to the Internet (via a proxy) for doing email etc. All users are strictly locked down, and there's strict device and access control.

In addition to this, each developer has an 'engineering' machine. This has full admin access, and the user can do whatever they like. However it is connected only to the engineering network (no route to the Internet).

In most software development contexts this could be seen as extreme, but in orgs that have conflicting requirements of high security and developer freedom, this is a common solution.

To answer your question, yes it is common to allow developers admin access, but this doesn't always mean admin access to a machine that could cause information security issues.


Is including a secret GUID in an URL Security Through Obscurity? I know that this question is a little bit on the side of Opinion/Discussion, but I think there's a provable answer to it.

I think the common view of "Security Through Obscurity" is that the security will only hold up as long as an attacker cannot guess the way in.

In environments where massive attacks or common attack vectors are known, this is often much simpler than many people believe.

However, I think a large number of people do not classify requiring a username/password combo as requiring as a version of "Security through obscurity"

My question is this:

What (security) difference (if any) is there between the following two urls with respect to security (please note caveats listed below):

Prototypical URLs:

[encrypted scheme/protocol SSL]://[user]:[password]@[domain]
[encrypted scheme/protocol SSL]://[domain]/[user][password]

Examples:

https://a93010d0-cc6c-11e2-8b8b:0800200c9a66@www.example.com
https://www.example.com/a93010d0-cc6c11e28b8b0800200c9a66

Caveats:

Assume that these urls are being accessed by a low-level HTTP client, NOT a web browser. (i.e. the client is not keeping a record of requests, and is trusted -- I know that low-level != "trusted", but I'd like to factor our browser caching as a difference in this question).
I know that there are known ways to "predict" GUIDs that might have been generated if you have sufficient knowledge of the guid's source machine, and the time (and probably other factors). I do not know if you can extract this information from a sample guid. Assume that Guids are generally not predictable.
Even though I've already attempted to address this with 1, let me be clear: Humans never directly interact with these URLs (or even see them without digging into a compiled application)

Is the second URL form an example of Security Through Obscurity? Or simply less secure because of the fewer protections afforded by the client?

I'll try to answer the question itself without lecturing you on what to use and what not to use.

Taking your assumptions into account (which are quite daring assumptions, IMO)

SSL is used.
No logging anywhere.
The GUIDs aren't easily predictable.
The password is strong.

Then no, this is not security by obscurity. This is security by, well.., security. Your security depends on the attacker's inability to guess/know the password, and not on the the attacker's inability to guess/know how your system works. Your password is, in some way, your key. As long as your security depends on your key, you're alright.

Now, I'm afraid you're attempting something like storing directories on your server with those GUIDs and passwords and then link to the resources inside those directories. In that case, absolutely not! Don't do it! Passwords aren't supposed to be treated that way.


A DDOS attack by uploading a few hundred large files - whats stopping anybody? I am new to the IT Security field and am essentially a developer as opposed to a networking person hence the question may be a dumb one

I am writing a REST service exposed to the internet which accepts files to be uploaded to the server, and the size could be up to 5 MB. We have restrictions on the server side to not accept content greater than 5 MB, but this happens after the fact - meaning after the content has been uploaded and we are already reading it. Which raises a few security related questions on DDOSing of our service:

What happens if a bot net starts uploading 100MB files from 100 machines at the same time. This would mean that our network pipes are clogged handling 10GB of data while slowing down our real customers? How do we even detect such an attack where the number of servers are so less. Can we configure our IT infrastructure to block requests by payload size based on the service being accessed (we have multiple services hosted in our IT infrastructures)?
Can you turn back requests from your IT infrastructure whose content length goes beyond a certain limit?
In general, for a server which accepts POST/PUT requests, how do you protect from an attack which just uploads files on the POST request, even though the server is not meant to accept file uploads?

but this happens after the fact

Really? What webserver are you using (you forgot to tell us). Apache, nginx, lighttpd all have options to limit the size of a request (the request is dropped if the client supplies a size greater than the limit in the header or the limit of data is received by the server).

If you want to validate the size before uploading it then you'd have to implement a non-sandboxed java applet.

  This would mean that our network pipes are clogged handling 10GB of data

No - not if you implement QOS based traffic management. This can be tricky to do on the operating system (again you forgot to tell us what this is) - if you are using Apache then have a look at mod_qos or mod_bw

  How do we even detect such an attack

Active monitoring + automated responses - If you're using some flavour of Unix, then ensure your webserver is confiugred to cap the post size and LOG MESSAGES on violation, then set up fail2ban to process those messages.

  Can you turn back requests

Yes - see above. The only caveat is that someone trying to kill your servers may tell fibs in the content-length header (which is optional anyway).


How was the Xbox One password verification compromised? So, we have this article:

http://www.engadget.com/2014/04/04/xbox-live-five-year-old-hacker/

Apparently, using nothing but spaces the local account (with an obviously saved password... I hope) was compromised. I am guessing that the password was TRIMMED before comparison and the dad had a password of merely spaces to begin with. Although, for a dad who is a "security researcher" this is seems awfully naive.

So, what does Security.SE think? Is there an affirmative source that confirms how this exploit works?

The consensus seems to be that the Xbone trims terminal whitespace from entered passwords.
When the kid enters a password of just spaces, trimming whitespace results in a blank password.

So, the kid has both entered a blank password and entered a non-blank password. The empty password error handling routine chokes on this strange state of affairs and hijinks ensue.


Securing a Windows Guest Account I know that a person with physical access to a computer can do almost anything to it. My main concern with my Windows 7 guest account is privacy and sandboxing. I don't want a guest user to have access to files on other user accounts, and I don't want him to download malware that affects more than just the guest account.

I'm using Truecrypt full system encryption, and my regular user and administrator accounts both have strong passwords. Permissions are set so that C:\Users\MyUser can only be accessed by MyUser. If I were to allow a guest to log onto my computer and turn my back for a few hours, is there any reasonable way he could break out of the guest account, get past file permissions, or install malware that affects other users?

I keep my computer up-to-date constantly, and from what I understand zero-day exploits are pretty rare. The only thing I can think of that a guest can do to get around his limitations is install software that takes advantage of an unpatched exploit in Windows or some 3rd party service that has super user privileges. So I assume I'm relatively safe allowing a guest to have access to my computer. Is this a false assumption?

Note: My primary concern is ignorant or irresponsible guests. If I know someone wants to hurt me, I won't let him use my PC.

Firstly, this point:

  I'm using Truecrypt full system encryption

When the system is powered on, and the user has physical access, this is pretty much irrelevant. Disk encryption protects you from theft where the thief either isn't aware of the need for, or cannot acquire the key. It won't help you if the key is in memory and the system in use, as files are all being decrypted on demand.

Now,

  I keep my computer up-to-date constantly, and from what I understand zero-day exploits are pretty rare.

Yes and no - it depends what in - in the core of Windows I would say "probably". However, any software you have installed that runs as Administrator, or the SYSTEM account (Windows Services) may be a target for privilege escalation. Once privilege escalation has occurred, anything goes.

That's the scary view, now for a little dose of reality. Does the person you intend to leave your computer alone with know enough about your system to:

Know you have a vulnerable package and what it is.
Know how to exploit it.
Know how to cover their tracks so you don't notice immediately on returning.

If I had to guess, I'd say the odds of this are quite low; however, if you're worried you do have options, such as backing your system up beforehand, or providing them access to your network on their own hardware, which is easier to isolate (but comes with its own set of problems).


SSLV3.0 Poodle Man-in-the-Middle scenario I have gone through the answers in this thread
SSL3 "POODLE" Vulnerability.

In the first answer,the following has been mentioned.

""The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256)""

Could you explain how could the last byte turns out as '7' with a probability of 1/256

--Added--

I understand that the 256 is the number of combinations of the last byte possible.

I am just not able to figure out what all ways can the client request be modified such a way that 1 in 256 times the result is 7 and the server will accept the request?

Updated to better explain what's going on after referencing the original paper.

Since it's block encryption and the attacker is tricking the user into sending requests, the attacker can force the requests to 1) have a full block of padding and 2) have a block where a specific byte of the secret cookie is at the end. Since the block cipher decryption is the same per block across a single stream, the attacker takes the whole block of padding and replaces it with the whole block ending with the specific cookie byte then sends it off to the server. If it gets accepted, the attacker knows that the last byte of the cookie block decrypted to 00000111, which (through some math on the encrypted values) allows the attacker to calculate the unencrypted byte of the cookie. If it doesn't work (which it won't 255 times out of 256), then the attacker needs to force the user to submit an entirely new request (which means an entirely different round of encryption, so it'll have completely different encrypted values even if it's the same unencrypted data). Only after it's accepted will the attacker change values, and what he/she will change will only be the part of the cookie that's in the last byte of the block he/she is swapping.

Old post:

Since there are 28 = 256 different values a byte can be, and since the attacker can't predict what the output will be, he/she must guess until that last byte has the one value that is valid, namely a value of 7.

By the nature of the XOR operation, if one input is static then there is exactly one value for the other input that will produce a desired output. So if the c7 is 01010101, only an e7 of 01010010 will result in 00000111. The attacker can't know c7, but he or she can change e7 (since that's just the value of the byte in the request) until the server doesn't return an error.


How to sniff ECDH HTTPS traffic? Our company currently sniffs encrypted RSA traffic using a network tap.
Would this still be possible using ECDH? I guess not.

Are there commercial alternatives, like placing an agent on the application server to receive all information the application on it receives?

Are there open source alternatives who could do the same job?

I suppose that by "sniffing" you mean "obtaining the cleartext traffic".

Basically, SSL/TLS has been designing specifically to ward off attackers who want to do that kind of sniffing. When organisations want to do it nonetheless, there are two main methods, that both break the SSL security model:

The sniffer may be configured with a copy of the server's private key. This is simple enough in practice (in particular, the sniffing apparatus can then be purely passive on the network), but it works only for a specific server whose private key is under control of the organisation. It won't work for arbitrary external servers (i.e. when employees do some Web browsing).

This method works for cipher suites using RSA, DH or ECDH. Crucially, it does not work for cipher suites using DHE or ECDHE. Pay attention! This is an important and often overlooked point: ECDH and ECDHE are not the same thing. Many people talk of "ECDH" when they actually mean "ECDHE". The reason why knowing the server's private key does not allow passing sniffing of connection with DHE/ECDHE is basically called forward secrecy.
The sniffer may do a full Man-in-the-Middle attack. In that model, the sniffer creates dynamically a fake certificate for the server that the client wishes to connect to. The client accepts that fake certificate because the corresponding root CA, which is entirely under the control of the sniffer, has been installed as a "trusted root" in the client system (this is where the SSL security model is bent: if you trust a CA that lies to you, then you're done for).

This kind of MitM is active and thus more invasive in network configurations, but it will work with arbitrary target servers, and also with all cipher suites (RSA, DH, ECDH, DHE, ECDHE...). Many vendors sell appliances that can do such things.

It shall be noted that this MitM system does not work with client certificates (but client certificates are quite rare in practice). More importantly, it is not hidden: users can notice that the certificate comes from a non-standard root CA.


How do I generate a blowfish password hash in Ubuntu? What's the command line to generate a blowfish password hash? I can't seem to figure this out at all. Apache's htpasswd only supports bcrypt, and openssl passwd doesn't even do blowfish hahes (but it does do blowfish encryptions with openssl enc).

Most sites point me to using $2a$ which is bcrypt, not blowfish ($2y$). Also a lot of places seem to confuse blowfish password hashing with blowfish file encryption. There are a lot of online sites which will generate blowfish hash for you, but I don't want to use an untrusted third party.

What other secure linux tools can I use to generate a blowfish password hash? I want to be able to define the two digit cost parameter as well as the salt.

bcrypt is based on blowfish. The difference between $2a$ and $2y$ is something else:

There are multiple implementations of bcrypt. And one of them, called crypt_blowfish, had a security related bug, drastically reducing the actual password space. Fixing this bug, however, caused existing bcrypt hashes to not match the passwords anymore. So this implementation started to use $2y$ to identify the fixed implementation, while still being able to maintain compatibility.

$2a$ of the original unix implementation and $2y$ of crypt_blowfish are identical.


What do web trackers know about/think of me? Many companies use HTTP cookies, flash cookies, and other analytics to track visitors on the web and classify them. How can I find out what my web profile is currently, and what these trackers are currently classifying me? I understand there is not one canonical profile as different sites may have access to different data but how can I know more about how they might be classifying me?

Information is overwhelming

As someone who writes these sort of applications for a living I can tell you that you are protected by anonymity in numbers. Most companies see the sea of people, not the individuals.

If you're talking about a web stalker or researcher, the main question shouldn't be "What do web trackers know about me." Assume they know everything. Almost all information is public record these days (in the States):

Where you bought your house? (public record)
Where you went to school? (facebook, reunion sites, etc)
How old you are? (facebook, linked in, stack exchange, reunion sites)
Who are you related to? (facebook, ancestry.com)
What's your e-mail address? (online and offline surveys, anywhere it's posted on the web)
Your home address? (facebook, foursquare, public record, magazine subscriptions, e-mail subscriptions, reverse phone look-up)
Were you arrested? (public record)
Were you convicted? (public record)
Where do you work? (linkedin, facebook, company website)

Search for your name, your phone number, your home address on Google. Want to see a satellite image of your house? What your house looks like from the road?

What can you do to prevent someone from finding you?

live off the grid (cash only)
provide disinformation
use IP phones like magicjack
use a PO box
use anonymous e-mail accounts
don't complete surveys
complete surveys incorrectly
don't verify information cold callers (eg. Caller ID says "Unknown"... "Hello, Mr. Jones?")

If you're concerned about companies sharing your information, they already do. The profile for each companies depends on what they're interested in. Most companies try to stick with their corporate mandate or charter.

For instance a company that you may use at work for business travel isn't necessarily concerned with your buying habits on Amazon.com, however they may be part of the same network of advertisers that show that you also go to Amazon. The advertisers use this to try and sell their services to other companies. They won't specifically single you out. They may show you ads for places that you frequent when you're on a partner site. So if you visit Delta Airline's website and check for ticket prices, you may see an ad on Amazon, Google, Yahoo, Youtube, etc... You might get offers for luggage on Amazon (or suntan lotion if you searched for tickets in a tropical environment). Luckily they don't do this at the moment because user experience tracking tells them people freak out about this stuff.

Anytime you see third party cookies, these are transmitting information to a server that keeps track of your "profile" off of the site you're visiting.

It's not only online.
Another place that people don't think of that tracks all of their purchases is their credit card company. Companies like Visa, Mastercard, Paypal, and American Express all have records (many times multiple records) for the same account holder and their purchase patterns, histories and frequencies.

One of the scariest profiles out there can be found by creating a Google Plus account. Google (Microsoft and Apple) see everything that is transmitted over their devices and software, whether it's an android (or apple) phone, a browser, a web search, or a DNS lookup (8.8.8.8,8.8.4.4). It's all logged in some form or fashion.

Most browsers keep your cache, history, and saved passwords as features. Also they store cookies. If someone wanted to exploit a browser it would be easy to have it forward all of this information to one centralized location. Your computer and your personal electronics have the most information about you on them. Guard them for they are your identity in the modern age.

When I write an application for a client we usually try to pair their existing history (prior to a personal identifier) with the profile after they've provided some bit of information. If I submit a cookie to the end user, they likely don't know it. Then every time they connect from the same device using the same browser I can keep track of their actions. At the point they log in with another device or browser I can document the device, or a new browser, and pair that information with the existing info. If they send a link to a colleague I can track the colleague too. If they provide an address or a company name I can search online directories and build a deeper profile for a client. If they subscribe to a mailing list and I send them weekly emails I can tell whether they travel or not. (By the ip address of the device they check their email on, you can already do this by data-mining e-mail thread headers in your inbox as well).

I'm one of the good guys. Ethically it would be bad to try and exploit any of the information available. If I did this once I would risk all of my clients who depend on me for my professional services.

So you have two options... live off the grid for fear of the worst case scenario... or enjoy life because you have nothing to worry about. Bad things happen to people all the time. They usually don't involve your web profile.


Is my personal data at risk with global digital giant's services? The global digital giant's services like facebook/gmail/twitter/etc are not following standard password policies (like the standard password policies used by most of the Enterprises/Corporate).

For example there are no password expiry on these services (I'm using the passwords I created years back) and some of the passwords are not complex enough...

I believe these organizations are liable for the PII (Personal Identifiable Information) of users, hence the question is are risking them self (and users's data) by ignoring standard industry password policies/practices?

Or they manage it through some other mechanisms? Am I missing something here?

IANAL, but in my opinion a service is only liable for what it manages. So they shall ensure that only authorized admins can access PII, and strictly forbid it.

On the other hand, the password is chosen by the users, and the password security is under their control. ANY ACCESS USING THE PASSWORD IS SUPPOSED TO BE A LEGITIMATE ONE. Full stop.

The various password policies should be seen as a way to educate corporate users to security practices, by their intrinsic efficacity is often debated, including on SE site. Search for password policy for more...


A simplistic stateless alternative to HTTP basic auth for API's Many API's (services) today use OAuth, HTTP Basic Authentication or API keys to authenticate their users.

My goal is to find a simplistic secure way to authenticate users in a client-side webapplication in a stateless way for one service.

Authentication methods

Here's my view on some of the authentication methods:

OAuth seems like a great solution, but it looks very complicated to setup and seems overkill for just one service.
According to OWASP "HTTP Basic authentication is not secure
and should not be used in applications".
Using plain API keys in a client-side webapplication does not
seem like an improvement in comparison to HTTP Basic authentication.

Using encrypted tokens

My alternative idea is to use encrypted tokens which can be verified by the service.

The token's plaintext will contain the username, password &
the expiration date of the token.
The plaintext will be encrypted using a
secret key which is only known by the server.
The plaintext will be encrypted on the server using AES in GCM mode,
so that the integrity can't be manipulated.

The user needs to login with his/her username and password to receive a token. This token is send on every request and can be verified on the server.

To illustrate:

+----------+                                          +-----------+
|          +------      Login with user:pass     ---->+           |
|  Client  |                                          |    API    |
|          +<----       Send encrypted token      ----|           |
|          |                                          |           |
|          +------    Use token to authenticate  ---->+           |
+----------+                                          +-----------+

Verification

Verification can be done by:

Decrypt the token using the secret key.
Verify username and password.
Check if the token is expired.

Pro's

Possible pro's of this approach:

Tokens can be stored in localStorage to mitigate against CSRF attacks
and users are able to logout by clearing the localStorage.
Plaintext login information is not send on every request.
Tokens can expire.

Cons

Possible cons of this approach:

More load on the server by decrypting every request.
A token is bound to a specific server.

What do you think is a good solution?
Do you know other good alternatives?

Your proposed solution is almost identical to JSON Web Tokens (JWT), which are precisely that:

A stateless token containing information about the user
Signed and/or encrypted using shared secret or asymmetric key
Marked with an expiry timestamp

See https://jwt.io/ for more information. You would be very well served using this standard rather than rolling your own, as many well-tested libraries already exist for handling these tokens.

Note that it is generally unnecessary to store the password in the token, since the fact that it was encrypted or signed with your private key proves that it was created by your authentication routine. This gives the important benefit that you can have a completely separate authentication service, which verifies passwords and generates tokens, while your main application only knows how to read the tokens.

Regarding tying things to a particular server, you can handle multiple servers in one of two ways:

Use symmetric encryption, with the same shared secret installed on all your servers, but still impossible for anyone else to discover.
Use asymmetric encryption, and generate a different private key on each server which needs to create tokens, and deploy the corresponding public keys to each server which needs to read tokens.


How to chose a port to run an application on localhost? I'm considering developing a web application for my own usage on desktop, running on localhost, automatically launched at startup. I'll need to chose a port to do so. What I'm uneasy about is the ability of any other program to fetch what is available at this port.

I know that this could be considered a virus, but my impression is that listening to a port is something less disturbing than a keylogger for example. Actually an application could already use this port for legitimate purposes.

What are the best practices for choosing a port on localhost (if that's already a practice not so bad) and, if that's possible, securing it?

Check this list of unassigned ports
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
Better choose something after 49k
If you are using socket for IPC, use PF_INET family


What does a failed SPF record tell me from a DMARC Aggregate report? I just started receiving DMARC aggregate reports. I am trying to understand what it means for a Source IP to fail SPF. Does this mean that the domain that failed the SPF tried to send an email on behalf of my domain? (essentially spoof my domain?). If that is not correct, then is there a way to use this report to find out which domains are sending email on behalf of my domain?

Thanks

When setting up the SPF policy you are basically listing out the domains, subdomains and IP addresses that are allowed to send email for your domain. When the aggregate report states that the source IP address failed, it means that the mail was received from an IP address that did not appear in the list of IP addresses that are authorized to send email for your domain. So, as you said, somebody tried to spoof your domain name in the email, but SPF caught it because the IP address from which the mail came was not authorized to send email for your domain. It is most probably spam.


Is HTTP secure within a WPA2-PSK connection? I'm running a small, low power web server chip which creates a Wi-Fi access point using WPA2-PSK AES encryption. This chip is never connected to the public Internet or any other network. A client device may connect to this access point and receive HTTP pages. This is basically like connecting to your router's configuration pages, but the router is not connected to anything else.

My question is, since the only connection is already using WPA2, would using HTTPS instead of HTTP within that connection provide any additional level of security that I'm not already getting with WPA2?

It would definitely add an additional level of security that would keep communications confidential if your WPA pre-shared key is leaked.
Check this: Can other people on an encrypted Wi-Fi AP see what you're doing?

"So if you know the PSK for the network, and your sniffer catches the "4-way handshake" another client does with the AP as it joins, you can decrypt all of that client's traffic. If you didn't happen to capture that client's 4-way handshake, you can send a spoofed de-authenticate packet to the target client (spoofing it to make it look like it came from the AP's MAC address), forcing the client to fall off the network and get back on, so you can capture its 4-way handshake this time, and decrypt all further traffic to/from that client."


Can a PC hotspot signal be monitored for website URL address and content? A user is accessing adult websites using a PC hotspot connection. Can the signal be intercepted to identify website / content instead of installing monitoring software on the PC?

Most people use their personal hotspot because there is no way for their employer to see their traffic. I'm assuming that's the case here.

The hotspot becomes its own network, which means you have no legal or inexpensive way to break into it. "Stingray" is a device that is designed to do what you are looking for, but it is limited to law enforcement.

The only option here is to install something on the PC.

If you are the employer and not the employee (I assume it's actually the other way around) if you have endpoint protection software already installed, you might be able to prevent the use of hotspots, or simply pull the user's browsing history from the machine.


Can a computer virus be stored somewhere else than on the hard drive? Are there viruses that have managed to hide themselves somewhere other than on the hard drive? Like CPU cache or on the motherboard?

Is it even possible? Say I get a virus, so I get rid of the HDD and install a new one. Could the virus still be on my PC?

Plenty of places:

BIOS / UEFI - BlackHat presentation (PDF)
System Management Mode (SMM) or the Intel Management Engine (IME) - Phrack article.
GPUs - Proof of concept rootkit on GitHub.
Network cards - Recon 2011 presentation (PDF)
A Quest To The Core (PDF) - a good presentation covering everything from BIOS to SMM to microcode.

Modern hardware has a wide range of persistent data stores, usually used for firmware. It's far too expensive to ship a complex device like a GPU or network card and put the firmware on a mask ROM where it can't be updated, then have a fault cause mass  recalls. As such you need two things: a writeable location for that firmware, and a way to put the new firmware in place. This means the operating system software must be able to write to where the firmware is stored in the hardware (usually EEPROMs).

A good example of this is the state of modern BIOS/UEFI update utilities. You can take a UEFI image and an executable running on your OS (e.g. Windows), click a button, and your UEFI updates. Simple! If you reverse engineer how these work (which I have done a few times) it's mostly a case of a kernel-mode driver being loaded which takes page data from the given UEFI image and talks directly to the UEFI chip using the out instruction, sending the correct commands to unlock the flash and start the update process.

There are some protections, of course. Most BIOS / UEFI images won't load unless they're signed by the vendor. Of course, an advanced enough attacker might just steal the signing key from the vendor, but that's going into conspiracy theories and godlike threat actors, which just aren't realistic to fight in almost any scenario. Management engines like IME are meant to have certain protections which prevent their memory sections from being accessed even by ring0 code, but research has shown that there are many mistakes out there, and lots of weaknesses.

So, everything is screwed, right? Well, yes and no. It's possible to put rootkits in hardware, but it's also incredibly difficult. Each individual computer has such a variance in hardware and firmware versions that it's impossible to build a generic rootkit for most things. You can't just get a generic Asus BIOS and flash it to any board; you'll kill it. You'd need to create a rootkit for each separate board type, sometimes down to the correct revision range. It's also an area of security that involves a huge amount of cross-domain knowledge, way down deep to the hardware and low-level operational aspects of modern computing platforms, alongside strong security and cryptographic knowledge, so not many people are capable.

Are you likely to be targeted? No.

Are you likely to get infected with a BIOS/UEFI/SMM/GPU/NIC-resident rootkit? No.

The complexities and variances involved are just too great for the average user to ever realistically have to worry about it. Even from an economic perspective, these things take an inordinate amount of skill and effort and money to build, so burning them on consumer malware is idiotic. These kinds of threats are so targeted that they only ever really belong in the nation-state threat model.


Server monitoring for security We do a lot of web hosting management and have started to get into selling server management packages. However, we want to start monitoring servers for security related threats.

Our clients may use their servers for stuff other than web hosting and some might change by the day so this would require that they stay in constant communications so we could fine tune all our monitoring services to check for stuff not whitelisted, but this could prove to be a big bother if protocols are not followed especially if we configure LFD to terminate any process not whitelisted along with what another tool does when monitoring socks.

So the question is twofold:

What sort of issues should we be trying to detect?
How would you go about setting up generic monitoring to identify them? Preferably without having to involve our customers constantly.

What do we look for? -- A Security Expert. To Hire.

That is a 100% serious answer -- If you are asking this question you need someone in house who can answer it.  Selling a "security monitoring service" without an expert on staff is a Bad Idea. You will make a mistake, it may result in a client being compromised, and you won't have the expertise on hand to deal with it.  All of that makes you look bad, and much of it can be avoided by having someone with decent security knowledge on staff.
(Also expect that your customers will need their security assessments explained to them -- It's hard to do that if you don't have a handle on the technology used to do the assessing.)

After you've found your security expert you can proceed with deciding what to look at and how to approach security assessments and management.

The simplest and easiest thing to do is not look at anything and just make it your policy that all available patches are automatically applied to all managed machines.
(For suitably broad definitions of "simplest" and "easiest": You need some way of pushing out these updates.  WSUS or a commercial solution like Citadel/Hercules is a common solution on Windows, and Puppet or RedHat Network satellite servers are pretty common in the Linux world.)

This is a shotgun approach: Absent any other information you're just installing every patch available and hoping to plug some holes.  It works for a lot of environments, but it can also introduce mysterious breakage when you apply a patch that doesn't fix any particular vulnerability for you, but changes your system in a way that upsets the local software.

The rest of my answer looks at security assessment in two phases -- Outside-In and Inside-Out.  It is by no means comprehensive, but should give you some good ideas.

Outside-In assessments

The first big item in Outside-In assessments is to start proactively looking at your hosts for potential problems.

Tenable Networks Nessus vulnerability scanner is the flagship product in this space, with OpenVAS being a popular open-source alternative.
These programs scan hosts looking for vulnerable services as identified by "signature scans" -- Sometimes they will issue a false positive, but often they spot real problems that you may not be aware of.  If run regularly they can help you target specific patches which need to be installed on your systems, as well as allowing you to determine compliance with the patching policy (If everyone was supposed to be on FooServer 1.2.3 as of last month and someone is still running 1.2.0 there's a problem that needs to be addressed).

These tools basically automate what "hackers" have done since the dawn of hacking:

The other major "Outside-In" tool is a network IDS (and/or IPS) -- Something that sits on your network and looks for "things that just don't seem right".
Snort(Snort IDS) is the flagship here, and widely regarded as a pretty decent product.  A good network monitoring system can also help you catch "interesting" traffic patterns so you can look further into them to see what's going on.

A good IDS/IPS may not prevent a system from being compromised, but if configured properly they can isolate machines behaving suspiciously and prevent them from being used to compromise other systems on your network.  The ideal configuration for your situation is very much dependent on your environment, and something the aforementioned expert could help with.

Inside-Out Assessments

The first step in inside-out assessments is configuring systems for security - the absolute basics of making sure unnecessary services are stopped, default passwords changed, SSH switched to key-only logins, Configuring Fail2Ban, etc.
Any competent sysadmin should do this as rote habit, so I won't go into any real detail.

The next steps can really be taken in any order, but they are all more reactive (notifying you that a breach may have occurred) than proactive:

Log Analysis and Centralized Logging
Most Linux systems ship with LogWatch these days -- it has its problems, but it can be helpful on occasion.  Similar concepts exist for Windows networks: something to let you know when the system logs an "unusual" event.
Ideally you would run this on a centralized, secured logging server (so that if a machine is compromised and the logs erased you still have a record).
Checksum and Signature based system checks
A program that runs on each host and alerts you if a file that should never be changed is changed.  The flagship product here is Tripwire, but there are dozens of similar things available, and on modern Linux systems you can even hook the FAM Daemon to alert you when a file is being touched (so long as the attacker doesn't kill the daemon).
"That Doesn't Look Right" tools
This would be CHKRootKit and its ilk -- Things that look for known malware, rootkits, trojans, etc. that may have gotten onto your system.
Again, many modern systems ship with this tool or something equivalent preconfigured.
Draconian Measures
This includes things like "Kill any process which is not on this whitelist" -- They can enhance security, but the convenience (and/or usability) impact is often more than your users will bear.

Final Thoughts

Like I said, everything in this answer is just scratching the surface.  "Managed Security" is a vaguely defined term, and these are some of the more common things that are done. You will think of others -- evaluate them carefully in terms of risk, reward, and manpower in order to decide if you want to offer them (and what they should cost).

Some tips from experience:

Don't accept users' machines into the managed environment.
Make them let you build new systems from scratch, otherwise you will forever be ferreting out little problems here and there.  (In practice this almost never happens, but make sure the financial pain to the client is at least equal to the time your systems team spends trying to unravel the mess they inherit when you accept management of an existing environment someone else built)
Take away root/admin access when you assume management.
If your customers can still perform administrative tasks they may undermine everything you're doing.  Before you offer management as a service establish a clear policy for giving customers root (temporarily terminating management services), and for what has to be done before you resume management of a machine they've had root on.
(When (not if) you wind up going against tip #1 you'll use that same procedure to accept management of the disaster you're inheriting...)
Manage firewalls too
If you don't already, offer managed firewall services at the network level and limit the use of host firewalls where practical.
Having control over the firewall makes it easier to troubleshoot problems that may come up later.
Dedicate enough staff that you can perform the tasks you're committing to
Security is a full-time job.  At larger scales it becomes several full-time jobs.  Make sure you have the manpower and expertise to handle the workload you're accepting.  Scale up slowly.


querying user supplied URL, what are some best practices? I have a web application that imports data from third-party websites by accepting a URL from a user, querying that URL, and then parsing it for data.  I'm somewhat concerned about the tool being abused so I'm wondering what best practices I should implement to mitigate abuse.  Currently the tool is only available to people who have created an account so any abuse should be traceable to a particular account.

Specifically, I was wondering if the request I send to the third-party website should include any headers such as including an IP address of the original requester (similar to a proxy request).

Things that immediately come to mind for protecting other sites -

Verify users - at a minimum by email verification.
Per Domain Rate limiting. Both per user and global limits.
Per user usage limits. You can also spin this into a monetiser - heavier usage for a fee
Check Robots.txt on the remote domain and if it asks you not to run that particular request either don't do it or ask the user to confirm they have permission from the domain owner.
Make it clear in your ToS you will pass on user details to sites where abuse has occurred and withdraw services to the user.
Maybe offer an opt out for domain owners so that their site can't be scanned. If you do this make sure to verify they do own the domain first.

You also need to protect yourself. Remember all content pulled in from a URL could be user supplied (they may own the domain) and as such could be an attempt to exploit your own application.


Handling user login using asymmetric cryptography Is it possible to implement a login protocol with asymmetric cryptography instead of the hashed password method?

For example, while creating an account, the client generates a private/public key pair from a hash of the username, password and other additional data. The public key is then sent to the server with the username, and the server stores the username and the public key. When the user wants to login, he enters his password, the client regenerates the private key, signs a nonce with it, and sends the signed message to the server. The server is then able to authenticate the user as he knows the public key associated with the username.

Is there any flaws in this protocol?

And what would be the advantages over storing the password hash?

EDIT:
I actually found a quite complete answer here:
https://crypto.stackexchange.com/questions/1662/how-can-one-securely-generate-an-asymmetric-key-pair-from-a-short-passphrase?rq=1

It is a bad idea to generate the key for asymmetric cryptography totally on predictable data (i.e. user chosen password) instead of secure random data. By basing the key completely on predictable data the key gets the same predictability as the password used as input.

Still, asymmetric cryptography can be used for authentication/login but not in the way you propose. Typical examples are authentication with client certificates in TLS and authentication with a key in SSH. In both cases either the public key is known by the server (and associated with the user) or the server can derive trust to the certificate by building the trust chain to locally trusted issuer certificates.


Has networking using multiple "unrelated" connections to share an encrypted data stream been researched? I'm not exactly an expert, so I'm hoping you'll give me the benefit of the doubt and try very hard to make sense of this...

I've been thinking about a simple measure, which I'll call Multiple Networking, that may enable a computationally secure network.  The idea is that we use multiple connection points that don't give information about each other;  in other words, knowing information about one network connection won't reveal information about another network connection.

The essential framework behind this form of networking is that multiple connection points are used in some ways like a single connection.  Communication is done between groups of connection points.  The key element of this idea is that a third party can't gain access to all of the connection points.  Then the information shared between two parties can't be accessed by a brute force computational attack, since the third party (attacker) doesn't have access to all of the information shared.

I'm wondering if techniques like this already exist.  This is to help me determine my main question, "Is this a worthwhile research paper?".

A CLARIFICATION

Perhaps this will help explain what I'm thinking of.  If you were to look at the message from inside a network, if would look like a message from A to B, a message from C to D, and a message from E to F.  ONLY OUTSIDE OF THE NETWORK ARE THE MESSAGES COMBINED TOGETHER.  So it looks like a group of messages, but it is really a single message.  That way a third party has to figure out what messages are related in order to attack, eavesdrop, etc.  The idea is that this can't be done from inside the network.

ADDENDUM
I'd like to thank those below for trying to understand this.  I've thought about this idea some more, and this is a lot like a message that is split apart and sent through multiple Tors.  I guess the point I'm wondering about, though, is if there is a way to break up the message outside of the network.  It seems to be a fatal flaw to have the message pieces traceable to a single source, even if they're routed through multiple Tor networks.  This is still a work in progress, but thanks again for your patience.

The network technique of establishing single logical connections over multiple links is called inverse multiplexing. Channel bonding and VCAT are specific examples of inverse multiplexing. It's been use for a long time for various reasons.

Generally, I've seen inverse multiplexing used as a performance or operational enhancement, not as a security tool.


Usefulness of Server's Work Load given Timing Attack Resistance of Responses I've read articles in the past discussing the importance of having timing attack resistant responses for information where knowing the time for evaluation would leak information about the data being processed.  More than once the articles mention something along the lines of:

  If every response is handled in uniform time it is possible for attackers to know how heavy of a load your server is processing based on response times.

Basically, because an attacker knows your request takes N milliseconds to respond on a normal basis, the attacker can deduce when your server is under a heavy or light load. But I have yet to read a document that shows why this information would be useful.

My question was, does this side-channel leak any valuable information and what would that information be useful for? Also if this information is useful, how to mitigate in a way besides throwing more hardware at the problem?

If an attacker was attempting a DoS on a server, measuring the load could provide information regarding the success of a DoS as well as help the attacker determine how much more resources are required to further the attack.

This could be helpful if resources are not freely available. Perhaps the resources are busy doing other things and will be costly to change what they are doing. Another example may be if you are purchasing time on a botnet for a DDoS. There resources cost money.


Time server security error Today at work, we brought out some PCs that were not used for a long time (were not in use when I joined this company so I have no idea about their history). After booting one of them (Windows XP Professional), I found that the system time is not set, so I tried to use NTP and sync the system to a time server. I used the default time server, i.e. time.windows.com. However, when I attempted to synchronize, the following error message was returned:

  An error occurred while Windows was synchronizing with
  time.windows.com. For security reasons, Windows can not synchronize
  with the server because your date does not match. Please fix the date
  and try again.

What possible security reasons are meant here? What security threats are possible in the process of synchronizing a machine to a time server??

As one example, Kerberos requires time synchronization. If you connect to a time server that changes your time by a large amount, it could interfere with the operation of kerberos. There may be other protocols that depend on embedded timestamps for secure operation.

Also: some applications do not behave well if the time suddenly jumps. It may be possible that there are attacks based on changing the time. I don't know about Windows, but the NTP daemon on *nix systems tries to gradually adjust the time instead of jumping it -- for this reason.

A good way to sync with a time server (especially if your system clock is off by a lot) is to manually set the time "close enough" to what you can manage manually -- within a few seconds is best, within a couple of minutes is fine if you don't have a good time source. Then connect to the time server and the local time service / daemon can make smaller adjustments to the system time, possibly spreading the adjustments out over a longer time so that there are no jumps in the system clock.


End to end security for REST services, any emerging standards? I work with integration in the healthcare sector, where end-to-end security is important. We integrate with numerous SOAP services, and use the WS-security features to encrypt and sign requests and responses.

The requests and responses go through several middle tiers in our integration scenario. It is therefore important that the data itself is encrypted (message security). Using HTTPS (transport security) only protects the message until SSL termination.

We also integrate with REST-style services. AFAIK, there is no standard approach (like WS-security) to securing REST payloads.

Are there emerging standards for signing and encrypting REST payloads?

EDIT

The Amazon S3 service implements encryption. Not sure if S3 upload client uses SOAP or REST-style calls.
This master thesis is about REST security.

I believe you are asking about identity propagation through a RESTful stack.  In other words, you want to tie the request back to the original user so downstream systems can validate authorization on a per-user basis.  I have also been researching this problem recently.

At heart, no, there is no standard defined for identity propagation for REST services.  REST itself is not a standard, but rather an architectural pattern.

There are some libraries that provide integration with existing standards such as Kerberos (such as JAX-RS) or SAML via HTTP bindings.

Various approaches using JSON Web Tokens (JWT) are becoming popular, but this is more of a "roll-your-own" approach, which offers flexibility but at the cost of implementation risks.  This is somewhat bleeding edge.  The RFC for JWT was only approved in April, 2015.


Do modern Android devices provide access to their Secure Element in some way? I'd like to know if the latest generation of Android devices provide an application with access to their Secure Element in some way (other than by way of the NFC interface, which is #1 application of the SE), preferably by implementing a keystore that uses the service of their Secure Element?

My use case is storing and using a cryptographic key (e.g. an HMAC key, unique to the device), in a manner that is hard to copy to another device, or emulate. Without some hardware support (and I only see the secure element as a hardware basis), it looks like I'm doomed.

Since Android 4.3, material in the keychain can be marked as stored in a “hardware-backed key store”. This can provide secure element access, but the hardware backing can also be ensured by TrustZone, which doesn't leave the main CPU. There's no way to query what kind of hardware backs the keystore (embedded SE, removable SE, TZ, …). The API function name isBoundKeyAlgorithm is perhaps a more precise way to qualify the intent of this attribute.

There is no guarantee that the SE is available to application even when it is present. Technically, most Android phones have long had access to a (removable) secure element, the SIM card, but this was not available to applications. Phones with NFC have a better chance.

In older Android versions, it is possible to access the SE (if any) through Seek for Android, however this only works on a few development devices so it is not an option unless you can impose a particular phone model and a custom image.


Encryption for cloud storage Background / Requirements

using a Windows machine
hard drives are already (veracrypt) encrypted volumes
not relying on any cloud service provider to trust them with their encryption
file by file encryption on the local machine

Question

Is there any downside using a program like cryptomator for file by file encryption on a fully encrypted veracrypt volume? Mounting an encrypted drive to access a file which again is used to mount a drive seems weird / I fear the two encryptions may distort each other.

I'm also open for alternative solutions. I also looked into boxcryptor but from what I got my files are unencrypted on my drive and are encrypted/decrypted whilst up and downloading. I would like to see the files encrypted on my drive before uploading.

There is absolutely nothing wrong with encrypting files on a volume (hard disk) that is also encrypted. Encryption doesn't "distort" anything; it's a reversible mathematical transformation of the input data. The cipher neither knows nor cares whether the input data is already encrypted; there's no special flag saying "this data is encrypted already!" that might get somehow confused. It's all just data.

File contents in plain text: A
File gets encrypted using per-file encryption utility: ENCf(A) = B
Encrypted file gets stored on an encrypted file system: ENCv(B) = C
Encrypted file is read off of the encrypted file system (for example, to upload): DECv(C) = B
Encrypted file is uploaded to a cloud service: upload(B)
Encrypted file is download from a cloud service to an encrypted volume: ENCv(download(B)) = C
Encrypted file is read off the disk and into the per-file decryption utility: DECf(DECv(C)) = DECf(B) = A.

("A", "B", and "C" are placeholder variables for the actual data, not literal values. "ENCf" and "DECf" are the per-file encrypt and decrypt functions, using the key you supply. "ENCv" and "DECv" are the volume-wide (VeraCrypt) encrypt and decrypt functions, using VeraCrypt's key for that volume.)

Now, it is important to not mess up the ordering (some ciphers will tolerate this, but some will not); DECf(C) != B, and DECv(DECf(C)) != A (probably). However, in practice this won't happen. You can't even tell where files begin and end on an encrypted volume unless you decrypt (some of) it first, so you aren't going to do something silly like try to decrypt C using cryptomator* and then try to decrypt the result of that using VeraCrypt. If you can even see the encrypted file is there, it's already passed through VeraCrypt so the data you see if you read it is B, not C, and you can safely pass it to cryptomator or whatever.

I've actually built, with a friend, a simple tool for doing this using the open-source gpg program for the file-level encryption. It worked fine.

*I don't know cryptomator and am not specifically endorsing it.


Finding a specific malware sample for malware analysis purposes I wish to analyze the changes made by a specific virus. For example, Win32.Sality.
Where can I get the sample of this, or other similar, malware for testing?

Contagiodump blog and the spam folder are your best friends


Wireless network solution? WPA2/MAC Filtering problems In short we have 7 Mobile Casio Scanners that seem to be incapable of holding their Wi-Fi passwords, they sometimes lose them for no apparent reason.

We of course, cannot give out the wireless password as this would be giving out access to our LAN as a Wi-Fi password soon makes it's way around the business.

It's causing a headache for me and our IT as we have to input these passwords on a day to day basis and sometimes business is halted as we are out of the office.

I thought about creating seperate SSID's on our AP's for 'SCANNERS', from here I was going to give out the password but ensure that MAC Address filtering was turned on to allow only the scanners MAC's through.

I've since read that this is almost pointless as a simple packet sniff of the wireless you can see MAC addresses in the Wireless Handshake in plain text, from there you can spoof your device into using that MAC address and boom they would be able to get into the network.

Not a good business choice in my eyes.

Any ideas from anyone would be HUGELY appreciated!!

Thanks,

Matt.

Network Technician.

You could do the MAC filtering but also separation of LAN to dedicated VLAN so that if someone connects to it wont be able to browse network shares. This kind of functionality is on every normal enterprise switch.
Apart from separating it to dedicated VLAN, you would need to filter out all traffic except for only what is required by scanners. This kind of functionality is also in almost every managed enterprise switch. You could do it also on the router/firewall if you have one.
This way if someone bypasses your MAC filtering, he wont be able to browse local LAN, connect to the internet, or do anything else except for what scanners do, which is very low impact IMO.


Active Directory - Certificate Based Authentication - Multiple certificates for user First, I have very limited knowledge about AD.

Problem: I authenticating users on AD using user certificates. I want to authenticate user on various devices (including mobile devices). Each will generate its own certificate via a CA. The CA is tied up with AD, so user authenticates on AD via certificates.

On the question is: Can a user account on AD hold multiple certificate for a single user. Because in my case the private key will not be share between devices (Devices will connect with CA to retrieve its own identity cert)

Please help

In the Microsoft / Active Directory world, there are several ways by which certificate-based authentication may happen, but the short answer is: yes, a user can have several certificates.

In IIS terminology, that is called "certificate mapping", with the option clientCertificateMappingAuthentication (not to be confused with iisClientCertificateMappingAuthentication). There are two methods by which a given client certificate can be mapped unto a user AD account:

The account in the AD may contain a copy of the certificate (not the private key) in its userCertificate attribute.
The AD server may extract the UPN from the validated client certificate and use that as account name.

Since the userCertificate attribute is multi-valued, it can contain several certificates, so this works with what you are looking for. The second kind of mapping can be intricate to set up (the AD server must also have a certificate of its own, and there is a complex game with the "enterprise NTAuth certificate store") but means that a virtually infinite number of certificates, not known in advance, can map to a given user account.


Is emailing a password recovery code as bad as emailing a password in plain text? I am creating a mobile app where my password recovery feature involves sending a password recovery code (randomly generated string) to the user's email address. They get the code, then enters it within the app. The webservices check if the code is valid (this expires after 24 hours) and then if it is, the app takes the user to update their password.

I would use a password reset link but I'm not great at programming and I'm looking at alternatives for now.

In terms of security, is sending the randomized code to the user's email just as bad as emailing the password in plain text? Even though I will be using the Blowfish cipher to encrypt the code when it is stored in the database?

To clarify this is asking about emailing password recovery codes/tokens and not about passwords

No, it's not as bad. Personally, I'm not a huge fan of using email as a password-recovery mechanism just because there are so many "what if"s, but lots of respectable sites do it, so shrug.

The reason it's not as bad is that if you email a password, the attacker will have silent access to the account and the user will be none-the-wiser. And as @drewbenn points out, it also compromises every other site for which the user uses the same password, helps attackers build dictionaries around password patterns (if any), etc. With a recovery code, the code should be one-time use, and the user will know very quickly if it's already been used.


Buffer Overflow: Advice on exploiting int play() {

    int a;
    int b;
    char buffer[010];
    a = 0x41414141;
    b = 0x42424242;

    if (write(STDOUT_FILENO, "For a moment, nothing happened. Then, after a second or so, nothing continued to happen.\n> ", 91) < 0) {
        perror("write");
    }

    if (read(STDIN_FILENO, &buffer, 0xC) < 0) {
        perror("read");
    }

    if (a == 31337) {
        system(buffer);
    }

    else if (b == 1337) {
        readfile("flag.0");
    }

    else if (b == 42) {
        readfile("vuln1.txt");
    }

    else {
        write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
    }

}

int main(int argc, char *argv[]){
    play();
    exit(EXIT_SUCCESS);
}

I think what is happening is that with a buffer if size of 11, it's trying to add 12 bytes to it? Is that even close?

I'm such a newbie it's scary and I apologise if this isn't the right place for this sort of question. Any footholds into what to do would be greatly appreciated.

I've compiled it and ran it with GDB but getting nowhere fast

The 0x414141 and 0x424242 that are placed in books for educational purposes because these are simply the strings "AAAAAAAA" and "BBBBBBB" in hexadecimal notation.  Assigning them to integers has nothing to do with buffer overflows.

A much better example can be had by using a full program, and a function call that will allow us to know when the overflow happens.  For example, let's alter the program to:

#include <stdio.h>
#include <unistd.h>

void
fun(void)
{
    char buffer[10];

    if (read(STDIN_FILENO, &buffer, 60) < 0) {
        perror("read");
    }
    write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
    return;
}

int
main(void)
{
    fun();
    write(STDOUT_FILENO, "WILL NOT PRINT.\n", 16);
    return 0;
}

Since you're using read and write we are assuming a UNIX system, so let's compile it and run a couple of times.  Assuming that the program source is in buf.c:

[~]$ gcc -g -o prog buf.c
[~]$ perl -e 'print "A"x10' | ./prog
So long and thanks for all the fish.
WILL NOT PRINT.
[~]$ perl -e 'print "A"x20' | ./prog
So long and thanks for all the fish.
WILL NOT PRINT.

Perl is handy because we can control exactly the number of bytes that we give the program.  Since STDIN is connected to a pipe, we can give a varying amount of bytes, up to the hardcoded 60 bytes in the program source.

The first run gives what we expected, 10 bytes are places in the 10bytes long buffer.  In the second run the 10 byte buffer should have overflow with 20 bytes of input.  But nothing appears to happen.  Well, the buffer did overflow, but did not overflow far enough to hinder process execution.  Let's do more:

[grochmal@haps tmp]$ perl -e 'print "A"x30' | ./prog
So long and thanks for all the fish.
Segmentation fault (core dumped)

Good, that's what we expect to see from an overflow.  Now that we have a good input we save it and look at how the program works in GDB:

[grochmal@haps tmp]$ perl -e 'print "A"x30' > input
[grochmal@haps tmp]$ gdb -q prog
Reading symbols from prog...done.
(gdb) list
5   fun(void)
6   {
7       char buffer[10];
8
9       if (read(STDIN_FILENO, &buffer, 30) < 0) {
10          perror("read");
11      }
12      write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
13      return;
14  }
(gdb) list
15
16  int
17  main(void)
18  {
19      fun();
20      write(STDOUT_FILENO, "WILL NOT PRINT.\n", 16);
21      return 0;
22  }
23
(gdb) break 9
Breakpoint 1 at 0x40058e: file buf.c, line 9.
(gdb) break 12
Breakpoint 2 at 0x4005b3: file buf.c, line 12.

Since we added -g to the compiler line we have all debugging symbols (e.g. program code) we may want.  This makes it very easy to setup the break points where the interesting part of the execution happens.  We run the program with the input we just saved and check how the buffer looks:

(gdb) run <input
Starting program: /home/grochmal/tmp/prog <input

Breakpoint 1, fun () at buf.c:9
9       if (read(STDIN_FILENO, &buffer, 30) < 0) {
(gdb) p &buffer
$1 = (char (*)[10]) 0x7fffffffe800
(gdb) x/15wx 0x7fffffffe800
0x7fffffffe800: 0x004005f0  0x00000000  0x00400490  0x00000000
0x7fffffffe810: 0xffffe820  0x00007fff  0x004005d3  0x00000000
0x7fffffffe820: 0x004005f0  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe830: 0xf7dd0798  0x00007fff  0xffffe908

The buffer is only 10 bytes long, and we printed 60 bytes.  But that gives away 0xffffe820 which is the location where the program needs to return to (in main) from the fun() call.  When the buffer is overflowed, the bytes overwrite that.  Let's see it by continuing with the read call.

(gdb) cont
Continuing.

Breakpoint 2, fun () at buf.c:12
12      write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
(gdb) x/15wx 0x7fffffffe800
0x7fffffffe800: 0x41414141  0x41414141  0x41414141  0x41414141
0x7fffffffe810: 0x41414141  0x41414141  0x41414141  0x00004141
0x7fffffffe820: 0x004005f0  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe830: 0xf7dd0798  0x00007fff  0xffffe908

And now the program will try to return over to 0x41414141, which will cause the segfault.

(gdb) cont
Continuing.
So long and thanks for all the fish.

Program received signal SIGSEGV, Segmentation fault.
0x0000414141414141 in ?? ()

And it did!  As a bonus we have the 0x41414141 string you're using as an int assignment in your program, and now can deduce from where it comes.

The security implication of this is that I know exactly which part of the input overwrites that return value on the stack.  And, thanks to that, I can drive the program to any instruction within its memory allocation.

(In practice that's much harder today because several measures are there to prevent such overflows from finding useful places to return to.  But the concept is the same.)


Is it Possible to Prevent a Physcial Attack on Server in Remote Data Center? I've been using Amazon Web Services to run my Java application. However, due to high costs I'm looking into getting a dedicated server from Hetzner, a company based in Germany, which costs about 10-20x less than AWS.

However, after reading this question and seeing the following statement by @Daniel Rudy:

The problem with physical security is this:

If the attacker has physical access to the machine, then there is no security.

I'm concerned that anyone with physical access to my server could steal my data/application.

If I understand correctly, encryption will only help while the device is powered off but will do nothing to protect PC while running (since program will not run unless it is decrypted). I cannot encrypt the Java Jar since it will be running from Eclipse IDE (for debugging purposes) and needs to be visible in editor. Thus, anyone with physical access to the remote server (employees, technicians etc) could steal my data by sticking a USB device into the computer and downloading all my data / application (correct?). Moreover, there would be no way for me to detect that something like this ever happened.

In other words, unless I have complete trust in the people who run the company to secure physical access to my server there's absolutely nothing for me to do to protect my data. If the server is located in a foreign country (as Hetzner is) I would also need to trust the government of that country not to breach my data (as they can easily overpower any physcial barriers enacted by Hetzner). And if someone did steal my data I would never find out.

Are my assumption correct or is there something I could do on my end to protect myself?

I've been using Amazon Web Services to run my Java application. However, due to high costs I'm looking into getting a dedicated server from Hetzner...
I'm concerned that anyone with physical access to my server could steal my data/application...
In other words, unless I have complete trust in the people who run the company to secure physical access to my server there's absolutely nothing for me to do to protect my data. If the server is located in a foreign country (as Hetzner is) I would also need to trust the government of that country not to breach my data. And if someone did steal my data I would never find out.

I think it is incorrect to say there is absolutely nothing for you to do to protect your data. It would be more correct to say that it will be very difficult to protect your application and data from theft by Hetzner or the foreign government.
But, similarly, there would be nothing you could do (or rather, again, it would be very difficult) to protect yourself from Amazon Web Services stealing your application and data.
You will likely have to trust Hetzner in the same way you trusted Amazon Web Service.
I guess it is also incorrect to say you would never find out. For example, suppose Hetzner stole your application and then started publically selling it as their own product. You could then, for example, sue them (in international court, I guess) and probably be able to make a pretty good case.
What you could do on your end to protect yourself is make sure you have good validated documentation regarding your development timeline for the app and then if Hetzner or whoever steals your IP you could sue them...
Pre-emptively you could also put it in the contract that they will hold your app in confidence, etc, before you buy services from them.

Per the comments, there are other ways to try and secure your dedicated server. For example, there are datacenters that will rent you a lockable rack. You could install your own server in the rack and lock the rack shut with your own lock. Of course, you have to trust that the datacenter owner wouldn't cut through your lock, but at least if they did you would know about it next time you visited the datacenter.


How to GET security answer values via AJAX for user edit I have an issue where our app had an app scan issue.  The application is using GET to retrieve info for a user profile page (written in HTML/Javascript).  This page has the user's security questions and answers, but the answers are in plain text in the raw response.

What is the best way to handle this?  The user needs to be able to edit the answers (they are masked out) but we don't want to be open to attack, of course.

Is the best choice to use some fake text to show in the box and then check that fake text on save?  This option doesn't show the true number of characters for what they originally typed in.  Is there a better method?

I checked this security.stackexchange question but the answer doesn't say what method is best for this scenario.

Is the best choice to use some fake text to show in the box and then
check that fake text on save?

Yes, this sounds like the way to go.

This option doesn't show the true number of characters for what they
originally typed in. Is there a better method?

I would see that as an advantage. I would see little benefit in revealing the number of characters in the original answer.
I would also be tempted to store these answers in my database using something like bcrypt. This depends if there is any requirement for the answers to be verifiable by a human (e.g. in a call centre to authenticate the user). If not you could uppercase the answer and strip all non-alphanumerics. This would allow correct answers to be easily entered by users, with a small increased risk of hash cracking by an attacker (e.g. if they enter "Foo Boy's School" as opposed to "Foo Boys School" because it would be stored as FOOBOYSSCHOOL). Iterations could be increased though to account for this as this information should be used rarely. This would mitigate a situation where your answers table is exposed to attackers where they could then use them to carry out a password reset.
Again, this depends on how any password reset mechanism works for your system and your level of acceptable risk.


Admin Interface: Web vs Desktop I am working to build a system that requires an interface to control existing data and add new ones. It's really nothing complex, just a few objects related to users, organisation etc.

The problem is that my boss wants this admin interface to be built in native desktop client but I think it's creating unecessary overhead.

We are a small company and I am pretty much the only developer with near zero dekstop app dev experience excluding some swing I did back in Uni.

We will be using IP whitelisting and will allocate a dedicated server for both solutions but here are the differences in our thought.

Please advise me which is better. Is it worth the pain to build/maintain a dekstop app?

Boss' opinions

Desktop is safer since it stops random people from manipulating our data if they don't have the program
Rival company is employing this method. Currently they are no.1 in the market

My thoughts

Hoping for security by building a desktop app is security through obscurity at best
Unless we use sockets, it's gonna use HTTP anyways essentially making it the same as a web app, just on a different port
Web app is much easier to develop and doesnt have as much compatibility issues
Even employing OTP is easier here

There isn't really a security difference if both desktop app and browser app are properly built.  Yet, I would definitely lean towards the browser app because you get several features "for free" (e.g. PKI for HTTPS).

All security measures that are present in modern browsers can be built into a desktop app alright.  The problem is that that would likely require more development effort and allow for more places where mistakes can happen.

Let's have some fun with counterarguments now:

  Desktop is safer since it stops random people from manipulating our data if they don't have the program

LOL!  < sarcasm >Yeah, reverse engineering does not exist, and obscurity can prevent eavesdropping < / sarcasm >.

With the amount of computing power we have today security through obscurity is getting less and less possible.  A couple of megabytes of traffic dumped into a statistical model can construct a specification of how data is sent.  And, unless you will never repeat the same commands to the admin interface, you cannot escape from a statistical model by using obscurity only.

Your only option is encryption.  Which means you will need to implement full TLS.  And by full I mean TLS (you could use openssl for this part) and HSTS, and a revocation path for compromised certs, and a CSP would be good as well.  And all that carefully enough to not make mistakes.  Cryptography does not allow space for coding mistakes.

  Rival company is employing this method. Currently they are no.1 in the market

MasterCard still uses mainframes to process (some of their) Chipcard data.  And still send different clearing files in distinct EBCDIC flavours.  Shall we all use mainframes for payments?

You can still make mistakes in the web app and make it worse than a desktop app.  But there is a lot of documentation about securing web apps.

There are also good frameworks to build desktop apps that come bundled with TLS communication.  Using one of those (Python paramiko and Microsoft WIF come to my mind) is an option but see the next section:

Extra point

The Achilles heel (in terms of security) of desktop apps is their dependency tree.  A desktop app will require dozens of libraries, which may have security bugs.  You will need to keep an eye on the CVEs for all libraries.  And, if one of the libraries turns out to not be very popular, there will not be many bughunters looking at it.

(That's also true with unpopular JavaScript libraries though)

And finally come the desktop app updates.  You found that your desktop app is vulnerable to something and patched it.  Good!  But now you need to distribute the new version to everyone using it, including that guy who is working from home for the past two months.  OK, you may send him an email with the new installer.  But wait, can't the email be tampered with?  Or even in a more mundane point, can you be sure that he will update his app?

A web app is much easier to update.


Possible implementations of networked+encrypted filesystem Is it possible to implement scheme where remote server just share its filesystem (or resizable container file in it) and it's locally encrypted and mounted? And what is best practical method? (On linux.)

Example use is backup storage on not very trusted server.

Sounds like what you're looking for is encfs. It's FUSE layer on top of any existing FS which encrypts and decrypts on-the-fly, storing the encrypted version in the underlying filesystem. The catch is that file metadata (ownership, sizes, times) is visible, but content and names are not.

You can also use --reverse to go the other way around: make an encrypted view of an unencrypted fs -- useful for making rsync-friendly encrypted backups.

EDIT TO ADD
As pointed out by Æsahættr, another usable option is eCryptfs. This is an in-kernel FS driver, which means root permission is required. But it's very low performance overhead and much faster then encfs in my own tests. While the implementation is quite a bit different between the two, the way you use them is nearly identical:

encfs /base_dir/ /view_dir/
# or
mount -t ecryptfs /base_dir/ /view_dir/

By default, encfs scrambles filenames while ecryptfs does not, but these options are configurable. Also, ecryptfs adds much more per-file overhead than encfs does because it stores metadata in the file itself, while encfs stores it in a hidden xml file. Also, the --reverse option that encfs has doesn't really translate well to ecryptfs; ecryptfs has ecryptfs_encrypted_view but it probably won't work the way you expect it to. Supposedly this is a work-in-progress.

Both can use any filesystem as a base; including, for example sshfs. But bear in mind that file ownership and permissions  are stored as-is on the base filesystem, which could mean access-denied errors if you don't match things up correctly, or losing permissions completely if you base on a FS that doesn't support them.


Stealing client certificate using Cross Frame Scripting An application asks for userID and then it asks for the client certificate to authenticate. All the pages of the application are vulnerable to XFS. Now an attacker can get userID using XFS, but can it steal the user certificate too?

The private key of the client certificate does not leave the client during the TLS connection same as the private key of the server does not leave the server (see How does SSL/TLS work for more details). Thus it is impossible for the attacker in your scenario to get the private key.

As for the certificate itself (i.e. the public part). If the attacker manages to setup a server this way that it requests a certificate from the client (maybe need to configure the accepted CA) then the client will authenticate itself with this certificate (maybe asking the client first) and thus the attacker can get the certificate itself, with all the public information it contains. The same information can be accessed by any attacker passively sniffing the connection with the original server since the client certificate (i.e. the public part) is transferred in clear.


Are There Any Measurements for Web-Application Complexity That Positively Correlates to Num. Vulnerabilities? Web-applications have vulnerabilities. Generally, a more complex web-application has more vulnerabilities, compared with a simpler and smaller web-application. For example, white hat hackers have found 2400+ vulnerabilities for Facebook since 2011. But for a smaller website like Coinbase, white hats have only found 200+ vulnerabilities in the past 2 years, despite that both sites have very good bounty incentives.

My question is, are there any measurements for the complexity of a web-application? If so, are there any tools? One requirement is that the measurement shall be made from a black-box view, that is, no access to the source code. Also, it would be good if the complexity measurement is positively correlated with number of vulnerabilities inside the system. Or number of vulnerabilities found by white hat hackers in a year.

One idea is to use web spiders. Web penetrating tools such as Burp Suite has a web spider function. However, web spiders have many issues, such as handling user authentication and dynamically generated contents.

Whenever we submit an offer for a penetration test we are facing the same question: How complex is the application? Complexity leads to additional attack surface, which leads to a lot of tests, which might lead to a lot of findings which require a lot of documentation. This effort has to be reflected within the offering.

To determine the possible complexity we discuss the application from different points of view:

Code

How many code files?
How many lines of code?
How many functions?
Centralized input validation?

Representation/Features

How many forms?
Authentication available?
Session handling available?
User initiated registration?
Password reset?
Captcha?
Database access?
File download?
File upload?
Mail sending?
etc.

It is not unusual that a customer can't answer these questions. Taking a look at the application allows to get a feeling for it. A crawler like Wget or the according Burp module might help to collect the desired data. A simple grep/find lets determine the forms and other aspects responsible for complexity very quickly. But this kind of blackbox analysis always comes with some uncertainty.


Are files deleted before encrypting then formatted able to be retrieved? On a drive I have a folder of files, I then just soft delete these files (not wiping them or overwriting with any data). After I soft delete them I encrypt the drive and wipe it with a single quick format or regular format.

If I have no limit for money to spend to recover the folder of files, would it be possible? Will I only encounter encrypted noise/data or is that only if the drive is overwritten beforehand?

In what situations would data be recoverable and not recoverable?

Generally speaking, most but not all of the previously unencrypted data will be recoverable if the encryption and formatting process does not involve overwriting every single byte on the underlying storage device or issuing a (properly implemented) ATA Secure Erase command. In the case of non-self-encrypting rotational hard disks, the time cost of a Secure Erase is similar to that of overwriting the entirety of the drive through software; in the case of SSDs, or self-encrypting rotational HDDs, the time cost for a Secure Erase may very well be trivial: just discard the encryption key or possibly clear the block mapping tables; the data would still be there and readable in the latter case, but there is no way to figure out which part goes where because it consists of randomly scattered blocks. Also note that many SSDs are self-encrypting under the hood no matter what you do.

A modern rotational HDD can sustain around 100 MB/s in purely sequential write throughput. This means that a 4 TB drive will take about 4 TB * 1,000,000 MB/TB * 100 MB/s = 4,000,000 MB / 100 MB/s ~ 40,000 seconds (about 11 hours) to complete a single full overwrite pass (overwriting large swatches of storage to wipe it is one of the few reasonably common truly sequential workloads). The sustainable write speed scales roughly with rotational speed, so a 10k rpm or 15k rpm server drive will be able to sustain a higher write rate than a 5400 rpm laptop drive. Time to completion obviously scales directly with storage capacity and achievable write throughput. SSDs are much faster but still have finite write speeds, and for large SSDs, the time needed just may be sufficient to somewhat accurately judge what happened.

Assuming you are using a rotational drive and that the formatting process took significantly less than 2½-3 hours per TB of storage, it is reasonable to expect (likely significant amounts of) data remanence.

According to Microsoft KB941961 Change in the behavior of the format command in Windows Vista and later versions, in Windows Vista and newer (that currently means Windows Vista, Windows 7, Windows 8 and Windows 10, and very likely the corresponding server releases as well) by default formatting does do a single full overwrite pass of the partition being formatted; the old, pre-Vista behavior of simply writing new file system metadata is now referred to as the quick format mode. (Hat tip to TTT for pointing this out.) However, I am not sure whether this is really relevant in the case of using TrueCrypt, so would prefer to err on the side of caution. The time the formatting took (for a rotational drive, did the formatting take around one second per 100 MB of storage?) can be used to infer whether an overwrite has likely been performed.

In the situation described, it seems relatively likely that common off-the-shelf data recovery software will be able to recover significant amounts of previously stored, unencrypted data. Some of it will have been overwritten and thus not be recoverable, but much may be relatively easily recoverable using just software solutions.

To protect against this for data that has been stored unencrypted, you need to do at least one full overwrite pass over the whole device that will hold the encrypted data (the container backing device, in LUKS parlace) before you start using it for that purpose. It's your choice whether to overwrite with just a fixed pattern, or random data; remember that a fixed pattern encrypted with a throwaway key and a good encryption algorithm becomes random data. Overwriting with a fixed unencrypted pattern may reveal metadata such as amount of data stored and its location on disk (which can be used to infer e.g. file system, which in turn in principle can provide known plaintexts).

Unless you are a nation-state actor, a single overwrite pass is almost certainly enough with modern drives, and if you are a nation-state actor, you would have access to better people to ask for advice than random strangers on the Internet.


Is it bad practice to use GET method as login username/password for administrators? I work on web applications and as you know, having an administrator panel is a must in most cases. We can see that a lot of web applications have a specific login page for administrators in which there is a form (usually POST method) that admins can use to login their panel.

But because the field names are known, a hacker can attempt to crack the passwords even if some security methods are implemented.

So what is the problem with a simple GET key (as username) and its value (as password)? Why it's not used a lot or at least, is not suggested in many articles?

For administrators, user-friendly login pages are not really needed! Data will be logged in both cases (GET/POST) if there is a MiTM attacker.

But using this method, fields will be unknown expect for admins themselves.
 Here is a sample PHP code:

"category.php": (A meaningless page name)

<?php
if (isset($_GET['meaningless_user']) && $_GET['meaningless_word'] == "something"){
    session_start();
    $_SESSION["user"] = "test";
    header('Location: category.php');   // Redirect to same or other page so GET parameters will disappear from the url
} else {
    die(); // So it'll be like a blank page
}
?>

This would store the login link with password and username in the browsers history. It could also be accidentally be captured by things like firewall logs, that wouldn't capture post variables.


Encryption and Layers understanding If I'm right the SSL encryption take place in the application layer, but we can also have encryption in the Internet Layer.

Why are we using both, and why sites that doesn't have SSL are considered insecure even tho the information is encrypted in the Internet Layer anyway.

Also is it possible for anyone in the Internet to sniff packets of a site (ex. stackexchange.com) or the attacker should tap the cables outside of the building the servers are located.
And if we have encryption in the Internet Layer and Wi-Fi is physical layer why is it considered insecure to log in to a site without SSL in a public Wi-Fi network.

Thinking in "layers" can be confusing. Layers come from the OSI model which was meant for another set of protocols, former competitors of what became TCP/IP (the "Internet protocol" that we use nowadays). If you want to put SSL into the layers model, your more-or-less have to put it on layer 6 or more, but also below layer 4 at the same time, which does not work. The "layer model" cannot really digest SSL.

When you want security, when talking to "a server", you want several things:

Confidentiality: people who can spy on wires must not be able to understand the data you exchange.
Integrity: people who can plug on wires must not be able to alter the data while it transits.
Authenticity: when you talk to a server, you must have some reasonable guarantee that you are talking to the genuine server, not to some attacker-controlled faked.

SSL is "end-to-end": it ensures these characteristics regardless of how the data bytes are physically transported. Encryption systems applied on "lower layers", usually, lack this wide scope. E.g., when using a WiFi access point, there is some encryption which occurs between your laptop and the access point, but it stops there. The access point itself, and routers beyond that access point, will see the cleartext data.

There are end-to-end protocols which purport to integrate with TCP/IP at a lower level (e.g. IPsec), but they don't get used as widely as SSL for "usual browsing" because of historical tradition. Indeed, if you want some security between your Web browser and a Web server, then both the browser and the server must support the same relevant protocol and agree to use it; right now, the only protocol which "works everywhere" is SSL (which is why people concentrate on SSL support, which is why SSL works everywhere, which is why people concentrate on SSL support, which...).


Smartphone - Full disk encryption For desktop computers / laptops we have software like VeraCrypt for full disk encryption.

Say I have a smartphone which contains sensitive data like pictures, videos or even whole apps. I want to protect that data as good as possible, especially when the device is shut down.

Is full disk encryption possible with smartphones? If not, which alternatives do I have?

TL;DR: Android and iOS support full device encryption.

Android

Android versions above 4.4 (your device will almost certainly be above version 4.4) have the option to enable full device encryption. Some devices even come with it enabled out of the box. Android uses dm-crypt encryption, and there's a guide on how to encrypt an Android device here.

A section of the article (some things cut out)

  Start by heading into the Settings menu and tapping on “Security”. You
  can start the process by tapping the “Encrypt phone” option.

  The next screen will present a warning to let you know what to expect
  once the process is finished. If you’re ready to proceed, hit the
  “Encrypt phone” button.

  One more warning will present itself which tells you not to interrupt
  the process. Once you're ready tap the “Encrypt phone” button to
  proceed.

  The phone will then reboot and start the encryption process. A
  progress bar and estimated time till completion will show up, which
  should at least provide an idea of how long the process will take.

  Once it’s finished, the phone will reboot and you’re back in business.
  If you set up a lock screen password, PIN, or pattern, you’ll have to
  put it in now so the device will finish the boot process.

iOS

If you have an iPhone 3GS or later, an iPod touch 3rd generation or later, or any iPad then you can encrypt your device. Most modern Apple devices already use encryption by default. Apple devices use AES-256 encryption to encrypt devices (in 2012 the NSA approved AES-256 for storing top-secret data). Here is a guide on how to encrypt your Apple device.

A section of the article

  On devices running iOS 4–iOS 7, you can do this by going to the
  General settings, and choosing Passcode (or iTouch & Passcode). As for
  iOS 8-9, Passcode  (or “Touch ID & Passcode”) has its own section in
  the Settings app. Follow the prompts to create a passcode. You should
  set the “Require passcode” option to “Immediately,” so that your
  device isn't unlocked when you are not using it. Disable Simple
  Passcode so that you can use a code that's longer than 4 digits.

  If you choose a passcode that's all-numeric, you will still get a
  numeric keypad when you need to unlock your phone, which may be easier
  than typing a set of letters and symbols on a tiny virtual keyboard.
  You should still try to keep your passcode long even though Apple's
  hardware is designed to slow down password-cracking tools. Try
  creating a passcode that is more than 6 digits.

  Once you've set a passcode, scroll down to the bottom of the Passcode
  settings page. You should see a message that says “Data protection
  enabled.” This means that the device's encryption is now tied to your
  passcode, and that most data on your phone will need that code to
  unlock it.