Best email system to avoid hacking.
Discussion
b
hstewie said:
hstewie said: It's largely to do with conditioning.
Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
People are also too used to watching how passwords are cracked in films "They've got 2 characters.. 3.. now it's 4" rather than "you know it all or you don't know it"
God. Bloomin' films. Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
People are also too used to watching how passwords are cracked in films "They've got 2 characters.. 3.. now it's 4" rather than "you know it all or you don't know it"
Another reason is many operating systems limit the number of characters in passwords for some reason. So often a password is confined to eight or twelve characters even though doggywoggylollyjolly would be so much better than Dent1st or H0peful. There are huge databases of common passwords available along with pre-computed hashes - this is called a rainbow table - that can be used to attempt to reverse engineer a password and so on.
If you ever get interested this site is an education: https://crackstation.net/
It's actually about securing systems, rather than hacking into them, but you have to know how the attacks are done if you are to defend against them.
Don said:
Some thoughts on writing secure applications.
Your application should run in the context of a non-privileged account. Grant that account only the rights it needs. No more, no less.
Store your data in a secure database like SQL Server.
Do not use SQL Server “Mixed Mode” security. Use Windows Security. This removes the need for your database connection string to contain VISIBLE credentials.
Log your user in to your application. Require a strong password. Lock the account if wrong more than N times. N should be small.
Require random letters from a secret word as part of login. Reversibly encrypt the secret word using a certificate not stored in the database but stored in the secure certificate store and marked as non-exportable.
Remember bad guys steal databases – don’t let them use it.
Out of preference require two factor authentication using a secure, open-source authenticator application. A hardware device is preferable to a software one if practical.
Once authenticated give the user a token and check that token EVERY time the user accesses application data in the database. Server side. Every time. I mean it.
Only access SQL data through stored procedures. Grant your non-privileged account execute permissions on the procedures and nothing at all on the underlying tables.
Use only stored procedures. No dynamic SQL. Ever.
Never build SQL strings. Only use secure APIs to supply parameters.
Never store passwords. Ever. There is no need. Store a “salt”, salt the password, create a hash. Out of preference encrypt the hash using a public/private key combination stored in the secure certificate store marked as non-exportable. Do not store passwords: EVER.
If writing a web application encrypt and decrypt the Query String using a public/private key combination from a certificate stored in the secure certificate store marked as non-exportable. Legitimate users do not need to manipulate URLs if you have designed a usable application.
Never, ever write your own crypto. Out of preference use an open source, peer reviewed crypto library like Bouncy Castle. The Microsoft stack is fine but remember the Americans have had odd rules about crypto – I wouldn’t rely on that not happening again.
If you think that this lot is paranoid remember that the people who look after your money do all this and more and STILL some fkers manage to steal it. Mainly because users do hilariously insecure things. Think: Are you paranoid enough?
Your application should run in the context of a non-privileged account. Grant that account only the rights it needs. No more, no less.
Store your data in a secure database like SQL Server.
Do not use SQL Server “Mixed Mode” security. Use Windows Security. This removes the need for your database connection string to contain VISIBLE credentials.
Log your user in to your application. Require a strong password. Lock the account if wrong more than N times. N should be small.
Require random letters from a secret word as part of login. Reversibly encrypt the secret word using a certificate not stored in the database but stored in the secure certificate store and marked as non-exportable.
Remember bad guys steal databases – don’t let them use it.
Out of preference require two factor authentication using a secure, open-source authenticator application. A hardware device is preferable to a software one if practical.
Once authenticated give the user a token and check that token EVERY time the user accesses application data in the database. Server side. Every time. I mean it.
Only access SQL data through stored procedures. Grant your non-privileged account execute permissions on the procedures and nothing at all on the underlying tables.
Use only stored procedures. No dynamic SQL. Ever.
Never build SQL strings. Only use secure APIs to supply parameters.
Never store passwords. Ever. There is no need. Store a “salt”, salt the password, create a hash. Out of preference encrypt the hash using a public/private key combination stored in the secure certificate store marked as non-exportable. Do not store passwords: EVER.
If writing a web application encrypt and decrypt the Query String using a public/private key combination from a certificate stored in the secure certificate store marked as non-exportable. Legitimate users do not need to manipulate URLs if you have designed a usable application.
Never, ever write your own crypto. Out of preference use an open source, peer reviewed crypto library like Bouncy Castle. The Microsoft stack is fine but remember the Americans have had odd rules about crypto – I wouldn’t rely on that not happening again.
If you think that this lot is paranoid remember that the people who look after your money do all this and more and STILL some f
kers manage to steal it. Mainly because users do hilariously insecure things. Think: Are you paranoid enough?Don said:
God. Bloomin' films.
Another reason is many operating systems limit the number of characters in passwords for some reason. So often a password is confined to eight or twelve characters even though doggywoggylollyjolly would be so much better than Dent1st or H0peful. There are huge databases of common passwords available along with pre-computed hashes - this is called a rainbow table - that can be used to attempt to reverse engineer a password and so on.
If you ever get interested this site is an education: https://crackstation.net/
It's actually about securing systems, rather than hacking into them, but you have to know how the attacks are done if you are to defend against them.
8 characters was a hard limit for the DES crypt hash function, historically many systems which allowed longer passwords were simply truncating them.Another reason is many operating systems limit the number of characters in passwords for some reason. So often a password is confined to eight or twelve characters even though doggywoggylollyjolly would be so much better than Dent1st or H0peful. There are huge databases of common passwords available along with pre-computed hashes - this is called a rainbow table - that can be used to attempt to reverse engineer a password and so on.
If you ever get interested this site is an education: https://crackstation.net/
It's actually about securing systems, rather than hacking into them, but you have to know how the attacks are done if you are to defend against them.
bhstewie said:
hstewie said: Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
The problem is that many sites insist on some combination of a capital letter, number and special character. Sometimes all three. So just using a simple phrase goes out of the window.Sheepshanks said:
bhstewie said:
hstewie said: Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
The problem is that many sites insist on some combination of a capital letter, number and special character. Sometimes all three. So just using a simple phrase goes out of the window.My pet hate is systems that insist I change my password just before I go on holiday for a fortnight!
You'd -almost- think they do it deliberately
Sheepshanks said:
The problem is that many sites insist on some combination of a capital letter, number and special character. Sometimes all three. So just using a simple phrase goes out of the window.
That's true and annoying. I think the point still stands though that if you tell ten people that they have to choose a password and the minimum length is 8 characters most of them will literally go for 8 characters.If I do presentations and have to type my password in I often get comments about the length of it and I always have to politely explain that I work in IT so of course I have a long password (plus I'm a believer in trying to practise what I preach).
Gojira said:
Well yes, but "H0w much is that doggy?" should keep both sides of the argument happy, and not really be hard to remember.
But too long. 
And you find sites which don't accept special characters so you need to modify the password etc etc.And that's just one phrase. I tier passwords depending on how bad I think it would be if someone accessed as me, but even so I've ended up with a 2 page list of passwords hidden away.
boxxob said:
Dynamic SQL is perfectly fine (and sometimes preferable) if handled correctly.
Using Stored Procedures does not prevent SQL injection. However, parameterised statements should always be used.
If you need to encrypt the entire querystring to secure your application, then your application is not secure.
Beyond "don't write your own crypto", rather it should be 'don't write your own authentication system at all (thus ignore the previous paragraph re hashing and salting your password).
It is pretty ridiculous to see the number of known large organisations that that have had, for example, MD5- or SHA1- based storage taken long after they have been demonstrated to be insecure. (e.g. Linkedin and dropbox breaches). There are also plenty of applications still offering that sort of security, and there is a huge amount of systems being put to work on a daily basis by what can only be called 'cowboy' devs, mainly because businesses are so ignorant of it and don't care if it 'looks pretty'. These businesses also think that any old manager-type person can run an technical project and that either internal or hired teams will actually do the job correctly without oversight and without specific security details appearing in the specification.
Dynamic SQL can be safe if used correctly, I'll admit. It's just that a LOT of insecure code gets written with Dynamic SQL.Using Stored Procedures does not prevent SQL injection. However, parameterised statements should always be used.
If you need to encrypt the entire querystring to secure your application, then your application is not secure.
Beyond "don't write your own crypto", rather it should be 'don't write your own authentication system at all (thus ignore the previous paragraph re hashing and salting your password).
It is pretty ridiculous to see the number of known large organisations that that have had, for example, MD5- or SHA1- based storage taken long after they have been demonstrated to be insecure. (e.g. Linkedin and dropbox breaches). There are also plenty of applications still offering that sort of security, and there is a huge amount of systems being put to work on a daily basis by what can only be called 'cowboy' devs, mainly because businesses are so ignorant of it and don't care if it 'looks pretty'. These businesses also think that any old manager-type person can run an technical project and that either internal or hired teams will actually do the job correctly without oversight and without specific security details appearing in the specification.
Stored Procedures, called with a safe parameterisation system rather than sql strings pretty much preclude SQL injection attacks.
Interesting point about QueryString encryption. I also thought this until recently as the proper defence against URL manipulation is to validate each and every parameter against the logged on user server side prior to performing any processing or giving out information. Until recently when some infosec guys I work with got all bothered about this. It turns out that they view the QueryString parameters as data leakage. i.e. it gets stored in browser caches and buffers on disk and a forensic analysis of a machine will turn up this data. So if you care about parameters like client numbers or account numbers or whatever not leaking into browser caches then you need to encrypt them. Paranoid? Most certainly but QueryString encryption is easy to achieve with a filter inserted into the web server flow so why wouldn't you?
The people I work with wouldn't outsource their authentication to anyone. However I'd definitely agree that for big websites and the like it would be miles better to sign up with Microsoft or Google or Facebook or whatever and outsource the authentication problem to them almost completely. Let them do the 2FA stuff and get on with your own functionality.
And thanks for commenting! Always useful to get another perspective...
bhstewie said:
hstewie said: It's largely to do with conditioning.
Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
People are also too used to watching how passwords are cracked in films "They've got 2 characters.. 3.. now it's 4" rather than "you know it all or you don't know it"
Minor pedantic point, but "how much is that doggy" is a worse password because it's a common phrase, and easily cracked via dictionary/phrase search.Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
People are also too used to watching how passwords are cracked in films "They've got 2 characters.. 3.. now it's 4" rather than "you know it all or you don't know it"
"Correct horse battery staple" is better because the words are not implicitly related.
Always always always use a password manager, store highly secure passwords and always create a new password for EVERY site.
Stuff like 1Password makes it so easy to do this across all devices that you have no excuse for reusing any password anywhere.
TonyToniTone said:
Why would you go with gmail if you are a large supplier, they don't have a UK data partition?
What a poor suggestion.
Sufficient large UK organisations have performed their own due diligence and come to the conclusion that Google Apps provides sufficient security for many of their operations. It also meets government requirements for anything below secret data classification.What a poor suggestion.
This is either an example of groupthink, lobbying or just maybe that it is sufficient for these purposes.
I think it's fair to explore options, but I also think threads like this can turn into a bit of an IT geek-out (myself included) when the simple bottom line is that for most people either of Outlook or Gmail will be a sensible option provided people follow the advice around strong unique passwords, two-factor authentication etc.
Don said:
Dynamic SQL can be safe if used correctly, I'll admit. It's just that a LOT of insecure code gets written with Dynamic SQL.
Stored Procedures, called with a safe parameterisation system rather than sql strings pretty much preclude SQL injection attacks.
Most if not all languages have an ORM available that handles all this automatically.Stored Procedures, called with a safe parameterisation system rather than sql strings pretty much preclude SQL injection attacks.
If you ever find yourself writing raw SQL then you're probably Doing It Wrong.
Yahoo had a security breach in 2014 where email addresses were compromised. I suffered a hit during this one and had some emails diverted. I did not receive notification to renew a URL and lost it. Well, I say lost it, I could have bought it back for $10,000.
That breach was published, although it took some time for me to be notified.
Is this current revelation the same hack?
In 2014 the motivation was, Yahoo said, purely for financial reasons, but now it seems to be a country that shall remain unnamed, but is big, attacking the USA.
So is it the same attack and they missed come of the important stuff, or is this one different?
That breach was published, although it took some time for me to be notified.
Is this current revelation the same hack?
In 2014 the motivation was, Yahoo said, purely for financial reasons, but now it seems to be a country that shall remain unnamed, but is big, attacking the USA.
So is it the same attack and they missed come of the important stuff, or is this one different?
768 said:
Jesus, there are still SQL DB babysitters in 2016? I thought you lot had died out! 
Apparently not. I am in fact a Business Intelligence Dev/Architect (Design the thing, build the thing, keep the thing running), and the amount of st code thrown at DB's these days is just increasing. I did manage to over-optimise my new source DB the other week, which caused me an ETL nightmare (just taken over from contractor built warehouse 
) but all is now good 
bhstewie said:
hstewie said:The_Doc said:
If that's correct, and I have no reason to doubt it, why are we asked to create passwords in the format 'Password 1' ?
Why not make us create bigelephantprunemirror?
It's largely to do with conditioning.Why not make us create bigelephantprunemirror?
Most people will assume that "K1tchen $ink" is a stronger password than "how much is that doggy" even though the latter is simpler to remember.
People are also too used to watching how passwords are cracked in films "They've got 2 characters.. 3.. now it's 4" rather than "you know it all or you don't know it"
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff