alison
Member of DD Central
Sanctuary!!
Posts: 356
Likes: 99
|
Post by alison on Dec 17, 2013 13:42:27 GMT
Thanks, I have had a look but migration would be difficult as I have many old accounts and all need a seperate qif file. For me it is hard to read with low contrast so I will keep Quicken for as long as I can. Interesting that the installer is unsigned so setting off Comodo sandbox and it will only run as admin. No problem. I hadn't seen the new 2014 version because I was still using an older one however this thread triggered me to try the upgraded version. I agree the default theme is hard to read, but fortunately can be changed in the Preferences. It was unsigned for me too which is a bit careless of them.
|
|
|
Post by westcountryfunder on Dec 17, 2013 16:07:08 GMT
The trouble is that I would be completely lost without Quicken 2004 which can still be installed on Windows 7 (I haven't tried on W 8 but it was difficult on Vista which involved adding three extra files downloaded from the web). If anyone knows a current program which can import Quicken files without mixing them up I would really like to hear about it. I have tried a few without success. Have you seen this alternative package? www.gnucash.org/Personally I know nothing about it, but perhaps it could solve your current difficulties and, should you ever give Linux a try, there is a suitable version. The FAQs give an answer about importing Quicken files.
|
|
JamesFrance
Member of DD Central
Port Grimaud 1974
Posts: 1,323
Likes: 897
|
Post by JamesFrance on Dec 17, 2013 16:22:28 GMT
Yes I tried gnucash but it scrambled my accounts. My Quicken data is 10.7 MB and probably overloads most of these.
I don't have any problems with Quicken and prefer to check my accounts manually against bank statements, so not bothered about downloading.
|
|
james
Posts: 2,205
Likes: 955
|
Post by james on Dec 17, 2013 23:55:38 GMT
I would like to think that Assetz along with the other major players in the industry are doing a very good job securing the actual hosted website and associated systems, and this is something that we continually review for our own systems, however this thread has very valuably raised the point that we could all be doing a better job with helping users secure their own accounts. Each user making sure their operating system is uncompromised, fully patched, and has the correct security settings is just one small part of this. And whilst I would thoroughly encourage everyone to at least understand the strengths and weaknesses of Linux, no operating system will ever be able to perfectly protect all those who use it. Chris, on that topic, would you be kind enough to confirm or check that: 1. Your database server/s is configured to use ports or other connection IDs that are not the default ones, so it's harder for automatic scans to find it if it somehow ends up internet-accessible. 2. Your database server/s uses private IP addresses that cannot be routed via the public internet and you've verified that your connectivity provider really won't route them. 3. Your software uses different database login accounts for low risk and high risk operations and personal data access, to reduce the scope for data compromise if one part of the code is compromised. 4. Whether you use a middleware layer or stored procedures that restrict possible queries as additional protection against attacks, particularly for access to the most high risk data like login and personally identifiable information often used in security questions at other sites and institutions. 5. If using MySQL, that you have no accounts on the database server with % as the acceptable hostname, and if at a colo, that you have none that have wildcards that include the addresses of other customers at the colo. That you regularly audit this. 6. That customer email addresses, passwords and other sensitive information commonly used for security questions like date of birth, mother's maiden name or NI number are stored in properly salted encrypted forms and where possible that hard to reverse engineer methods - like storing only three quarters of a password's salted cryptographic hash - are used for storage when access to the plaintext is not needed, as with passwords. As an experienced pro yourself you're probably already doing those but no harm to ask, just in case. Just asking is one of the things consumers can do to help.
|
|
|
Post by chris on Dec 18, 2013 0:36:41 GMT
james - I'll answer as best I can. Having said security through obscurity isn't a valid option, freely handing out details of your architecture isn't always a great plan either! 1) Some services are on standard ports some aren't, all are firewalled. In my view this falls under security by obscurity, and given that port scans are automated and very accurate messing with port numbers isn't of great value. 2) Direct connections to the database server are not allowed, with SSH tunnels being used as and when we do need to connect remotely. A further tweak to this setup is planned for January as part of a DB version upgrade. 3) Yes, different database users are used for different operations with different levels of security (often with privileges escalated, where necessary, via stored procedures). This is also under active review and we are looking at a project to make this even more granular. 4) The database server provides pretty granular control over per table and per column access. Stored procedures are used for most internal operations on the platform beyond simple data access; and internal movements of money (such as placing a bid) are entirely segregated in a separate schema and only accessible via stored procedures with defined routes that the money can take. 5) We're using PostgreSQL rather than MySQL and the security is tighter than described. 6) Passwords are stored hashed with a cryptographically random salt, security questions are not currently which is already scheduled for change early in January as that has definitely been an oversight. Email addresses are not hashed as they are required to be accessible elsewhere in the system for marketing and notifications (although there are alternatives that I'll consider down the line). NI number is not stored, nor are the details of the ID check - they reside with a third party credit reference agency. No bank or credit card information is currently held, although with nominated bank accounts this information will be required. When that feature is implemented it's liable to sit within our segregated virtual banking system and only accessible via stored procedure. We have just completed an independent external assessment of our entire IT system (internal and public facing) including security and our disaster recovery plans. Whilst overall we are doing very well there are some minor recommendations that have been made that will be implemented asap. Two factor authentication via a device or mobile app is one of these recommendations, for example. This is part of a policy of continual assessment where there will be routine internal and external audits and penetration tests planned over the next year.
|
|
james
Posts: 2,205
Likes: 955
|
Post by james on Dec 18, 2013 1:08:36 GMT
Thanks chris, good answers and I'm happy to read that you're taking care of some of the potential issues and have a plan to proactively find more. Nice job on both the direct work and the communication about it! Security through obscurity is an interesting topic because it's frequently under-rated. While the popular place where I did root/DBA work actually published its whole security architecture it didn't handle money with that architecture, and I don't think you should. However, lets consider the last potentially significant widescale security vulnerability involving MySQL. That didn't affect any of the official distributions because it only affected those built with specific compiler options. A few hundred connection attempts to a vulnerable server might result in a successful connection to any account, regardless of password, giving the permissions of that account. But only if the hostname for the account was permitted, so not using % would block most of the potential attacks anyway. The expected result of that is botnet-based attempts to connect to every potential server on the internet to try to find the small percentage of self-compiled vulnerable ones. First levels of security there are firewalls and lack of internet routability. If something goes wrong with those, a default port will be the first target of such attempts, so you can substantially increase the cost of finding your server by using non-default values. Most of the attacks would probably just miss you if you weren't on the default. I don't know of any production servers that ended up compromised with data loss by this - the multiple layers seem to have worked well enough. So while it's imperfect, please do use obscurity where you can. It's one more bit of complexity and extra work for an attacker that doesn't hurt the legitimate users of the system. Just one more tool in the kit that'll slow down illegitimate users who manage to get inside your systems somehow as well. The defaults make nice tools for intrusion detection systems to use to identify an attack attempt once you're no longer using them. You can be confident that attackers will hit them first, so giving you prompt notification unpolluted by your legitimate accesses.
|
|
|
Post by chris on Dec 18, 2013 7:53:18 GMT
Well, it certainly isn't going to hurt to put it in place so I will incorporate it into our plans.
|
|
|
Post by gingergent on Dec 27, 2013 15:21:07 GMT
Whilst I think that provision of a nominated account for outbound transfers will bring a substantial improvement in risk, there are a couple of other areas that are worth looking at:
a) Security questions are useful, particularly if vague (did I grow up in a house, a town, a county, a region or a country? Only I know...) but specific ones like mother's maiden name are worthless. b) Showing all security question answers on the profile page is a bit daft; a shoulder surfer's wet dream c) I'm not keen on needing to have my banking details stored with GoCardless, or whoever it is, and protected by yet another password; many would be encouraged to protect this by a low-security password they could remember, but for me it just means I can't move cash into Assetz on demand even if I have my bank card with me! FC's system is much better on this front.
For similar reasons to (c), I'm not keen on having any more 'complex' security on account actions which can't actually compromise my net asset position. If someone wants to break the current login system and deposit funds into my account I don't mind; if they want to place bids (they'll be limited by my free balance) then I'll be miffed but would expect to be able to sort it out with Assetz as account fraud\misuse\whatever. If someone wants to sell loan parts at a loss or withdraw funds to a bank account other than my own then I'm going to get properly upset. The level of security required should reflect this. It's already hard enough coping with a robust password (broad character set + length) on a mobile, without needing to cope with switching between apps for a time-limited one-time code every time I want to place a bid. Risk is the combination of liklihood and impact.
|
|
|
Post by chris on Dec 27, 2013 18:38:32 GMT
Whilst I think that provision of a nominated account for outbound transfers will bring a substantial improvement in risk, there are a couple of other areas that are worth looking at: a) Security questions are useful, particularly if vague (did I grow up in a house, a town, a county, a region or a country? Only I know...) but specific ones like mother's maiden name are worthless. b) Showing all security question answers on the profile page is a bit daft; a shoulder surfer's wet dream c) I'm not keen on needing to have my banking details stored with GoCardless, or whoever it is, and protected by yet another password; many would be encouraged to protect this by a low-security password they could remember, but for me it just means I can't move cash into Assetz on demand even if I have my bank card with me! FC's system is much better on this front. For similar reasons to (c), I'm not keen on having any more 'complex' security on account actions which can't actually compromise my net asset position. If someone wants to break the current login system and deposit funds into my account I don't mind; if they want to place bids (they'll be limited by my free balance) then I'll be miffed but would expect to be able to sort it out with Assetz as account fraud\misuse\whatever. If someone wants to sell loan parts at a loss or withdraw funds to a bank account other than my own then I'm going to get properly upset. The level of security required should reflect this. It's already hard enough coping with a robust password (broad character set + length) on a mobile, without needing to cope with switching between apps for a time-limited one-time code every time I want to place a bid. Risk is the combination of liklihood and impact. I take on board all you've said. Specifically: a) I agree, this needs work across the industry and I am certainly planning changes in the new year for Assetz. b) Utterly agree. This is only even possible because the security questions are currently stored unencrypted which is a flaw in the way we're doing things that is being tightened up as a matter of urgency. c) GoCardless has worked pretty well for us and huge sums of cash have been deposited via it. There are a couple of short and long term projects in the pipeline that will make it easier to get cash onto our platform in real time, including via debit card. Hopefully I'll be able to announce good news on that in the next few weeks. The security you describe makes sense to a degree, although a lot of it is personal preference and there will be others who would prefer other schemes. I have a lot to think about regarding our security and authentication systems!! Hopefully I can come up with something that keeps the vast majority happy whilst providing a suitable level of protection.
|
|
|
Post by bracknellboy on Dec 28, 2013 8:00:22 GMT
<snip> b) Showing all security question answers on the profile page is a bit daft; a shoulder surfer's wet dream <snip> <snip> b) Utterly agree. This is only even possible because the security questions are currently stored unencrypted which is a flaw in the way we're doing things that is being tightened up as a matter of urgency. <snip> OUCH. Big time. I don't like that. At all. I also don't like that it has now been publicised on a public forum.
|
|
|
Post by chris on Dec 28, 2013 9:28:21 GMT
bracknellboy I had already mentioned it on the previous page when answering some really detailed questions on our system - and to any hacker looking at the site it would have been obvious. It's also true for all sites that let you edit your security questions and display your current answers on that edit page. If the information can be displayed on a page then it is stored in a form that is ultimately hackable if your server is compromised. This is why change password screens are unable to display your current password (other than being good practice), it's because it's stored in a form that makes it unrecoverable (at least without expending a vast amount of effort). I don't want to down play the risk as it is important that we change the way this works but in the overall scheme of things its a really minor issue given the already limited value of the information held in the security questions and the number of other layers of security that would need to be compromised before that information was accessible to a hacker. By the time they got that far into the system the security questions would be of relatively little importance.
|
|
|
Post by oldnick on Jan 26, 2014 14:11:28 GMT
I'm using LastPass but feel uncomfortable about storing lots of financially related passwords under one master password. Nothing is impossible in the hacking world, if enough resources are employed, and each password is still individually vulnerable to discovery I suppose. Nominated bank accounts for withdrawls are a must aren't they?
|
|
|
Post by batchoy on Jan 26, 2014 14:45:58 GMT
Nominated bank accounts for withdrawls are a must aren't they? Definately. Here's a little exercise for people who are so in love with retained userids and passwords (cookie or browser) and are members of FC and Facebook. - Turn off your computer.
- Turn your computer back on
- If it didn't log straight back in, think about how easy it is to login because you used a dumb password i.e. your username, password, 12345, qwerty wife's/child's/dogs name or some other readily identifiable piece of information about you or just read the post-it note stuck in the top right hand corner of the screen
- Once you are logged in, open your browser and use the bookmarks and,or browser history to navigate to the FC website.
- Using the retained data complete stage one of the login
- Read the security question and open Facebook in a new tab.
- Using Facebook see if you can answer the security question. Remember things like mother's maiden name might not be there but they can be surmised from the names of relatives particularly if they belong to your family group. Similarly names of schools may not be on your page but check out the pages of friends of a similar age
- Use the answer to complete the login.
- Now navigate to the FC transfer out page.
- It this point you need to send me a PM and I will give you the bank details you need to enter.
- Now click on the Transfer Funds button.
- Now how easy was that?
- Now think of the consequences had your computer been stolen on the first day of your two week vacation giving the thief time to put your whole FC portfolio up for sale at a discount.
|
|
mikes1531
Member of DD Central
Posts: 6,453
Likes: 2,320
|
Post by mikes1531 on Jan 26, 2014 17:09:55 GMT
- Using Facebook see if you can answer the security question. Remember things like mother's maiden name might not be there but they can be surmised from the names of relatives particularly if they belong to your family group. Similarly names of schools may not be on your page but check out the pages of friends of a similar age
One of the best suggestions I've heard is to select a friend that you know well -- not from your school days -- and use their data to set the answers to the questions. As an alternative, you could just invent answers, but those might not be so easy to remember.
|
|
|
Post by yorkshireman on Jan 26, 2014 17:40:13 GMT
- Using Facebook see if you can answer the security question. Remember things like mother's maiden name might not be there but they can be surmised from the names of relatives particularly if they belong to your family group. Similarly names of schools may not be on your page but check out the pages of friends of a similar age
One of the best suggestions I've heard is to select a friend that you know well -- not from your school days -- and use their data to set the answers to the questions. As an alternative, you could just invent answers, but those might not be so easy to remember. Use words connected with your line of business if it is an older type of industry, manufacturing for example, and intersperse with numbers. I defy anyone to sus that out.
|
|