/c/cybersecurity - Cybersecurity News & Discussion

2090 readers
4 users here now

A community for technical news and discussion of cybersecurity and closely related topics.

founded 4 years ago
MODERATORS
51
52
 
 

Can write blogs, discuss with each other and a lot more.

53
54
2
How do ASLR and DEP work? (security.stackexchange.com)
submitted 3 years ago by [email protected] to c/[email protected]
 
 

How do Address Space Layout Randomisation (ASLR) and Data Execution Prevention (DEP) work?
Address Space Layout Randomisation (ASLR) is a technology used to help prevent shellcode from being successful. It does this by randomly offsetting the location of modules and certain in-memory structures. Data Execution Prevention (DEP) prevents certain memory sectors, e.g. the stack, from being executed. When combined it becomes exceedingly difficult to exploit vulnerabilities in applications using shellcode or return-oriented programming (ROP) techniques.

55
 
 

It started (in recent times) with the USA accusing TikTok and Huawei of being capable of spying (nothing was ever proven), and now with China responding in the same way about Tesla vehicles (laden with cameras, sensors and network connectivity).

All valid concerns, and we do already know for a fact that allies are spying on allies, so they are not groundless concerns, but where does that leave electronic devices that are getting smarter and smarter? It's a concerning future because even if the manufacturer is not overtly assisting with spying, they could be infiltrated and have their information exposed (remember SolarWinds?). In fact, who knows if data from Tesla's in use at US military institutions, have not had their data exposed already in this way to any other foreign power?

Interesting times we live in, and to think our own military was banning all smartphones from their meetings years ago... now it will be smart watches, smart cars, and let's just hope we don't get smart clothing!

See https://mashable.com/article/elon-musk-tesla-china-sharing-data/

#technology #security #spying #Tesla

56
57
1
submitted 3 years ago* (last edited 3 years ago) by [email protected] to c/[email protected]
 
 

This is a technique I've come up with, intended to be an improvement on the norm, and on multifactor authentication. It is both more secure and more convenient.

Features:

  • Every password is one-use-only - a hacker can never impersonate a service to steal credentials and immediately use them to impersonate the user.
  • Passwords are necessarily unique to each service - so password breaches are not so useful to hackers
  • The service must also prove its identity to the user - to avoid phishing
  • Does not use biometrics - because they are easy to steal, and difficult for the owner to change once stolen
  • Does not require revealing anything personal like an address or state-issued ID, that could then be used to impersonate the owner
  • Does not rely on having possession of a particular object/device - this device can be lost, stolen, damaged, causing the owner to lose all his accounts.
  • There is no need to store passwords somewhere like a password manager - avoiding several extra security risks.
  • Master-passwords don’t need to be very long or high entropy. There are only a couple of easy-to-remember ones which are shared across the user’s digital life. All transmitted data, all logins, are nonetheless high entropy.
  • It can be done as a browser plugin - this way it is at least as convenient as a conventional login. It can also be done using an air-gapped memoryless calculator - this way you never have to enter your passwords into any computer, or write them down anywhere but that device.
  • There is necessarily a standardised waiting time after a failed login, to avoid brute-force attacks.
  • Any attack (phishing or otherwise) is identified immediately and an alert can be sent. It can be figured out what information the attacker knew.

So this system has many features no existing system I’ve heard of has. In combination they make it perfectly secure.

How it works:

Cryptography usually uses some kind of hashing function, where it is easy to perform the calculation but difficult to reverse it. The analogy is mixing paint. Given two paint colours, it’s easy to figure out what colour is produced by mixing them. But given the mixed colour, it’s difficult to find out either component colour. I’ll use notation AxB=C for the forward function, where multiplication is easy, but the reverse function - given C find A or B - is difficult.

Here the user has two master passwords, PA and PB, which are the same for all services. He also has a device which performs the calculation AxB, to generate new temporary passwords. The calculator can be built into the browser, the OS, on the command-line, or on an air-gapped device.

Signing up to a service: The user provides the service a username and his two login passwords: PA x serviceID, PB x serviceID.

Login process:

  1. The user provides his username
  2. The service provides: PA x serviceID x date.
  3. The user checks this against his own calculation of PA x serviceID x date
  4. If correct, the user provides PB x serviceID x date
  5. The service checks this is correct. Then the login is complete.

This is as convenient as a conventional login process - assuming the calculator is built into the browser. Just enter your master passwrods and the browser will do the rest. But if the calculator is air-gapped, this technique has perfect security.

More details:

So the “something you have” and “something you are” are not required. If you’re a fan of two or three factor authentication you can incorporate them into this system. The login process can also be tweaked to force the user to check that the service's login is valid.

serviceID can be just the company name, or some other word which is the same for every user of the service, and shown on the login form. It can also be unique unique to each user, defined by either the user or the service (the service can remind the user of his serviceID)

The date could also be any unique or pseudo-random number. It could be displayed on the login form, to avoid timezone problems. Anyway the same date (and therefore the same login) can never be reused. Probably the date is rounded to 5min intervals, to the user has to wait 5min after each failed login attempt.

The user's passwords can be quite simple. High entropy is added to the login during the calculation. And if somehow hacked the passwords are easily changed.

This technique is easy to implement. A single browser or OS, and a single website/service could unilaterally start using this system. Or the details could be strictly defined as an internet standard.

There is no obstacle, political or technical. We could have perfect security, married with perfect convenience, today.

58
 
 

MOSP is a platform for creating, editing and sharing validated JSON objects of any type.

The goal is to gather security related JSON objects, in the first place aimed to be used with MONARC.

You can use any available JSON schemas in order to create new JSON objects via a web form dynamically generated and based on the selected schema. It is possible to interact with MOSP programmatically thanks to its API (OpenAPI specification).

You can export MOSP objects for MISP (MISP galaxy). See the this video as example.

59